#maas 2013-02-18
<snovaki> hi, do you have a tutorial on how to setup a highly available maas? in our config it provides dns resolving to our nodes and we really don't want to miss that.
<racedo> roaksoax: we are getting "mirror does not support the specified release (precise)" when enlisting the first host to a maas from 12.04.2
<racedo> any clue?
<melmoth> racedo, i had somehing similar last week.
<melmoth> it was something about deb-proxy
<melmoth> sqiud-deb-proxy
<melmoth> i must admit i was a bit lost on how we fixed it
<racedo> melmoth: ok
<racedo> melmoth: negronjl and I are trying to figure it out
<melmoth> https://bugs.launchpad.net/squid-deb-proxy/+bug/1087145
<ubot5> Launchpad bug 1087145 in squid-deb-proxy (Ubuntu Quantal) "maas proxy prevent nodes access cloud archive " [Undecided,Confirmed]
<melmoth> now, i have no ida how we fix it, we try 10000 things
<melmoth> and reverted back
<melmoth> untill it work, but i did not undertand why it work
<melmoth> we try: adding .archive.canonical.com in  /etc/squid-deb-proxy/mirror-dstdomain.acl
<racedo> ok
<melmoth> as well as in /etc/squid-deb-proxy/mirror-dstdomain.acl
<melmoth> and in  /etc/squid3/squid.conf  , we added
<melmoth> acl localnet src 83.150.34.0/24
<melmoth> http_access allow localnet
<racedo> ok
<racedo> awesome melmoth your wisdom will get us to have some late lunch now, if it works...
<melmoth> never work with an empty belly.
<melmoth> it makes your brain process data in a bad way
<racedo> melmoth: true
<roaksoax> racedo: restart squid-deb-proxy
<roaksoax> melmoth: that should have been fixed on the squid-debproxy side already
<roaksoax> racedo: and yeah you need to allow the local network too
<melmoth> it was not last monday (on 12.04)
<roaksoax> melmoth: yeah is aw it later on the week
<roaksoax> anyways, I
<roaksoax> 'anways I'm off
<melmoth> take care !
 * roaksoax is in US Holiday + sick :(
<lifeless> roaksoax: :(
<lifeless> roaksoax: thats no fun
<racedo> roaksoax: thanks, take care
#maas 2013-02-19
<roaksoax> smoser: whne you have a chance, could you please review/approve:
<roaksoax> https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579
<roaksoax> https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions/+merge/147460
<roaksoax> thank!
<smoser> roaksoax, 2 comments, that i'll add to review.
<roaksoax> smoser: cool thanks
<smoser> review updated.
<smoser> sorry that took so long
<roaksoax> smoser: thanks!! no worries :)
<roaksoax> smoser: updated!
<smoser> roaksoax, my only comment is on the drop of 'maas-commission' user
<smoser> why did that go? or am i just reading it wrong
<roaksoax> smoser:  because it adds more complication on replacing users with iLO3
<roaksoax> smoser: and I'm not sure whether it would work
<smoser> well, it added more complication in *all* cases.
<smoser> but it was deemed necessary/important
<roaksoax> smoser: right, so I don't know whether you can replace a user in iLO3, and don't have HW to test it
<roaksoax> smoser: either way, a different password is created
<roaksoax> smoser: so I think it no longer makes sense to have 2 different users
<roaksoax> smoser: that's one of the things that created issues at the drill
<smoser> well you dont have to *replace* a user, do you?
<smoser> you delete then add, or add then delete.
<smoser> right?
<smoser> i understand that we dont hav a way to easily test this, but that should'nt be justificaiton for removing code that was deemed necessary previously.
<roaksoax> smoser: it was deemed necessary to differentiate in what stage the user was added right?
<roaksoax> there was no other reason why we did that
<roaksoax> just only to differentiate what stage added the usre
<roaksoax> is that still necessary?
<roaksoax> rvba: around?
<rvba> roaksoax: hi
<rvba> What's up?
<smoser> roaksoax, i believe it was deemed necessary to avoid deleting a 'maas' user (and corrupting maas usage) if a node booted into enlistment.
<smoser> i think.
<roaksoax> rvba: so, since bigjools is in leave... I was wondering whether you could help us get the GenericIpAddressField thing in MAAS rather than in django
<roaksoax> rvba: the technical board adviced to implement that on the maas side rather than on the django side
<roaksoax> rvba: and we need that for sru
<roaksoax> smoser: we don't delete IPMI users actually. And we don't correct cause if the node boots into enlistment/commissioning, if it has been previsouly added to MAAS, then it will use the credentials it has there regardless of whether they are maas-commission or maas username's
<rvba> roaksoax: too bad we can't SRU Django.  Technically, this should adding GenericIpAddressField in MAAS should not really be complicated (but I'll look into it).  What about the other feature from 1.4 that we use?
<roaksoax> rvba: the other 2 patches are good to go
<roaksoax> rvba: but will require external testing. The only thing is to move the genericIPAddressField to maas instead of django
<rvba> "the other 2 patches are good to go" thank goodness for that!
<roaksoax> :)
<rvba> roaksoax: I'll have a look at this tomorrow.  Can you file a bug for this please? (maybe there is already oneâ¦?)
<roaksoax> rvba: sure I'll do that if there's not one :)
<rvba> ta
<rvba> roaksoax: please add a reference to the tech board decision in the bug's description.  So that everyone will know why we're doing this.
<roaksoax> rvba: ack!
<smoser> roaksoax, i thought that the general flow/idea was:
<smoser>  * if a system boots into enlistment, create a new ipmi user 'maas-commission'
<smoser>  that was only to be used for the commsisioning turn on (and would only be ever used for that)
<smoser>  * in commissioning (after admin acceptance of node), the 'maas' user is adde,d and from there out, the 'maas' user is used for power control
<smoser> by removing the 'maas-commission' user, you potentially report to MAAS-SERVER-X credentials from MAAS-SERVER-Y. thats at leas tone fallout from removing the maas-commission user.
<smoser> but thats probably not that big of a deal.
<smoser> the point is, though, that we very explicitly decided to use this temporary "first-commission only" user.
<smoser> and you're dropping that.
<smoser> Daviey, was involved in that discussion, perhaps he has other thoughts.
<roaksoax> smoser: we never remove the maas-commission user, we replace it
<roaksoax> or at least that's how it works on iLo1
<roaksoax> smoser: the only difference was that there was a different user name, and obviously a different password
<smoser> roaksoax, my concern (possibly un-founded) resulted from readingg lines 31-35 at https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579
<roaksoax> so if the node had user 'maas' and then for some reason commissioning run, it would have created a new user/[pass and updated maas, or if it failed to update, it would have a different user/pass in the bmc than what it is stored in maas
<smoser> not commissioning, enlistment.
<roaksoax> smoser: right, so it is exactly the same case
<smoser> the 'maas-commissioning' was explicitly there for enlistment
<Daviey> smoser: I'm not emotional either way.. that just seemed a sane way
<smoser> as enlistment potentially (i think very unlikely) results in accidentally breaking something for someone
<smoser> (ie, if they accendentally pxe booted off a new network... something i thought then was un-likely)
<roaksoax> look, if the node is set to 'Ready', and it enlists again, it will change the creds in the BMC either way
<Daviey> well, that was slightly different
<smoser> not if it enlists to a new maas.
<smoser> or a maas it did not intend to enlist to
<roaksoax> smoser: in iLO3 yes
<roaksoax> i mean
<roaksoax> iLO1/2 yes
<roaksoax> it would have *replaced* the user regardless of what user it would have been
<roaksoax> smoser: so if the BMC had user 'maas', and it enlisted against any other MAAS, the 'maas' user would have been replaced with 'maas-commission
<smoser> previously, that would not have happened.
<roaksoax> smoser: it would
<smoser> at least that was not what we intended.
<smoser> the goal before was that enlistment would create a maas-commission user
<smoser> and only ever break or change a user named 'maas-commission'
<roaksoax> smoser: yes, and we agreed that that user should be *replaced*
<smoser> i dont think "replaced" matters.
<roaksoax> smoser: exactly, which means that maas-comission or only maas doesn't matter either way
<smoser> surely you're not suggesting that previously "maas-commision" would "replace" "maas" user
<smoser> as that would be stupid, and the same as deleting.
<roaksoax> smoser: that would have happened if you would enlist that machine to a different MAAS
<roaksoax> smoser: if you enlist the machine to a different maas, it will replace the existing 'maas' user with 'maas-commission'
<roaksoax> that's how it
<roaksoax> that's how it always worked
<roaksoax> because we decided to have a temporary user/password combination that would later be replaced by the 'maas' user
<roaksoax> but then it was *replace*
<smoser> roaksoax, you're missing something. or i'm missing something
<smoser> i dont care what happens on commission
<roaksoax> smoser: so 1. enlistment would create maas-commission in User3. 2. commissioning would replace User3 (maas-commission) with user 'maas'. If that machine is enlisted in another MAAS, the User3 (whjich was previously 'maas') would be replaced by 'maas-commission' again
<smoser> well, that was a bug then.
<roaksoax> smoser: so using only 'maas' makes more sense
<smoser> well, other than it is destructive
<smoser> in enlistment
<smoser> which is why we had this 'maas-commission' user
<smoser> but you're dropping that.
<smoser> even if the implementation was broken, it was still there in concept, and now you're removing it.
<smoser> if its known broken, i'd just make sure we remove all 'maas-commision' strings anywhere.
<roaksoax> smoser: well then the whole IPMI stuff needs re-factoring to support those 2 things differently
<roaksoax> smoser: but won't be able to say it works 100% until i can test that with iLO3
<smoser> roaksoax, well, for now then i think its probably best to pull it completely
<roaksoax> smoser: ack!
#maas 2013-02-20
<rvba> roaksoax: Hi Andresâ¦ I need to test quite a few things before I can fix bug 1130232.  Do you have the precise django package that we intend to SRU (i.e. the one *without* the genericipaddressfield.diff patch)?  If you don't have it handy, could you please create itâ¦ that would help me a great deal.
<ubot5> bug 1130232 in MAAS "Implement GenericIpAddressField in MAAS rather than django." [Undecided,New] https://launchpad.net/bugs/1130232
<roaksoax> rvba: howdy!! sure give me a sec
<roaksoax> rvba: and re on the comments, yeah I was looking this as a patch because this should only apply to precise, and not quantal :)
<roaksoax> but i guess that's clear now
<rvba> roaksoax: it is clear.  I'm still a bit unsure what's the best solutionâ¦ but what's sure is that we will have to carry this damn field one way or another.  I mean in MAAS' code and not as a patch on Django.
<roaksoax> rvba: yeah!! it is a blocker for sure! but something needed to be done to satisfy the tech board.
<roaksoax> rvba: ok just uploaded to ppa:maas-maintainers/experimental
<rvba> roaksoax: thanks a lot
<roaksoax> should take a while till it gets accepted, built and released (~20mins)
<melmoth> hey http://jujucharms.com/charms/precise/nova-cloud-controller/config does not mention vlanmanager mode for the network
<melmoth> does it mean it s not possible to use vlanmanager mode with a maas installed openstack ?
<racedo> roaksoax: we are hitting https://bugs.launchpad.net/maas/+bug/1116700
<ubot5> Launchpad bug 1116700 in MAAS 1.2 "CNAME not added if PXE iface is different from first one in DB" [Critical,Fix committed]
<racedo> btw I hope you feel better :)
<racedo> any clue what's best if we wanted to stick to maas-developers/stable
<roaksoax> racedo: i could make a new release
<roaksoax> so you guys using an interface which is different from eth0?
<roaksoax> for the PXE booting and it is not generating the CNAME's"?
<racedo> roaksoax: yes, thats the problem
<roaksoax> racedo: are you hitting this with a costumer?
<racedo> we see a name in the maas web ui but it never gets added to the bind zone file
<racedo> roaksoax: yes
<racedo> we are onsite
<roaksoax> racedo: s/costumer/customer
<roaksoax> racedo: ok, so I think I can prepare a package with the fix included, but it will take me a few to test it
<racedo> so all the nodes that pxe boot from eth0 get added to the dns file after enlisting
<racedo> and the node (just 1) that boots from eth1 is not added but we get a name created and shown in the web ui
<racedo> roaksoax: ok, thanks for that
<racedo> we'll be here (NJ) for the day
<roaksoax> racedo: only today?
<racedo> roaksoax: today until 6 and tomorrow all day again
<roaksoax> racedo: ok cool, so that gives me some time :)
<racedo> sure man, no rush :)
<roaksoax> racedo: what else would you need? What iLO version are they using?
<racedo> 1.33
<roaksoax> racedo: ok so old implementation works well then
<racedo> but we are hitting some issues with version 1.29 they fail though
<racedo> roaksoax: we have ipmi 1.33  working fine and 3 hosts with ipmi 1.29 failing but they will try to upgrade them
<racedo> btw we are using ppa:maas-maintainers/stable
<roaksoax> racedo: ok, can you manually access IPMI with the maas credentials?
<racedo> roaksoax: no, they ping and that's all we get
<racedo> we think it's on the nodes' ipmi side
<roaksoax> racedo: right, but can you access with admin credentials?
<racedo> roaksoax: no, it's stuck, nothing happens, we think it's faulty i'm going to double check
<roaksoax> racedo: ok!
<racedo> roaksoax: ok they just upgraded the ipmi to 2.66 and this is what happens https://pastebin.canonical.com/85181/
<racedo> BMC error
<roaksoax> racedo: what about if you use the admin credentials?
<racedo> roaksoax: just got the credentials
<racedo> it works
<racedo> roaksoax: https://pastebin.canonical.com/85182/
<roaksoax> racedo: alright, so something is busted in the IPMI creation stuff
<roaksoax> racedo: the new precise update should be able to fix that
<roaksoax> (i hope
<roaksoax> ra	unless you provide me with output of what happened during the enlistment process
<racedo> you mean freeipmi-tools pkg?
<roaksoax> to see if it was able to successfully detect IPMI
<roaksoax> racedo: yeah that might be it, it might have failed
<roaksoax> to install
<roaksoax> racedo: are you guys using a proxy?
<racedo> no
<racedo> oh squid-deb-proxy
<roaksoax> racedo: right, so you probably need to allow the enlistment/commissioning images to access a proxy
<racedo> we got the last version apparently: https://pastebin.canonical.com/85183/
<racedo> roaksoax: ok, what would that do?
<roaksoax> racedo: yeah but the commissioning images also need proxy access
<roaksoax> racedo: give me a sec!
<racedo> sure man
<roaksoax> racedo: do this: https://pastebin.canonical.com/85185/ and pastebinit for me please
<racedo> https://pastebin.canonical.com/85186/
<roaksoax> racedo: ok so it seems that the user gets added correctly, but what is not done correctly is to provide a privilege for it
<racedo> roaksoax: ok
<racedo> and can we set the ipmi to allow it?
<roaksoax> racedo: can ytou do something like this? https://pastebin.canonical.com/85187/
<roaksoax> and then try to stat the node
<racedo> trying hold on  a sec
<roaksoax> racedo: ok, so I have a package that I just uploaded to ppa:maas-maintainers/testing that I will test, and then release in ppa:maas-maintainers/stable
<racedo> roaksoax: we are reenlisting it now
<roaksoax> racedo: cool
<racedo> roaksoax: thanks for the package too!
<racedo> roaksoax: you fixed it!
<roaksoax> racedo: cool!! I wonder why it didn't work out of the box as it should have!
<roaksoax> probably due to the older ipmi version
<racedo> oh that could be the case
<roaksoax> racedo: ok, the package should be published really soon
<roaksoax> ~10 mins or so
<roaksoax> if not less
<roaksoax> racedo: its done! you should be able to upgrade now
<racedo> roaksoax: thats awesome!!
<racedo> trying it now
<racedo> roaksoax: fixed
<racedo> roaksoax: many thanks again :)
<racedo> roaksoax++
<roaksoax> racedo: no probs. just confirm it upgrades and works fine :)
<racedo> it has upgraded fine
<racedo> and now the host can boot out of eth1
<racedo> confirmed
<roaksoax> cool
#maas 2013-02-21
<roaksoax> rvba: howdy!! thanks for work on the genericipaddress filed
<roaksoax> rvba: One thing though, I don't oppose merging this upstream, however, shipping it as a patch we would have ensured that this would have only affercted precise. Now that it is being merged, it will also affect quantal
<roaksoax> and in quantal we will not use GenericIpAddressFiel from django
<roaksoax> rvba: so just wanted to make sure you guys are aware of that
<rvba> roaksoax: Hi.  In my code, I detect which version of Django we are using and only do the monkey patch if django.VERSION = 1.3
<roaksoax> rvba: ok cool then :)
<rvba> So the quantal version will use the field from Django itself.
<rvba> I think it's better to put this upstream because it mean all that code gets tested everytime we make a change to the code (testing by the unit tests suite)
<roaksoax> rvba: awesome then!!
<rvba> means*
<roaksoax> rvba: for sure
<roaksoax> rvba: alright, so once it lands in maas/1.2 i'll prepare a new package, upload it to stable
<roaksoax> rvba: upload a new django to PPA as well
<roaksoax> and cleanup to start testing
<rvba> roaksoax: ok, I'll land it now and then we can start testing it.
<roaksoax> rvba: ok it is all in ppa:maas-maintainers/experimental for testing. It is building now though
<rvba> roaksoax: it's building in the daily ppa too :)
<roaksoax> ok cool :)
<roaksoax> rvba: once tested I'll upload to raring
<roaksoax> and that should be almost all we need to SRU
<rvba> roaksoax: the recent change only impacted the 1.2 branch.  The raring package uses trunk.
<roaksoax> rvba: right, but not in Ubuntu archives
<roaksoax> rvba: ubuntu archives will have 1.2 until the SRU is done
<rvba> Ah ok
<roaksoax> once that happens, we can upload trunk to ubuntu archives
<rvba> roaksoax: btw, we need to fix bug 1123986 before we SRU MAAS.  we're in the process of fixing it.
<ubot5> bug 1123986 in MAAS 1.2 "multiple juju environments in maas" [High,Triaged] https://launchpad.net/bugs/1123986
<roaksoax> rvba: ok! Note that having different juju environments won't really help much though :)
<roaksoax> rvba: cause the network is the same so things can still collide
<roaksoax> rvba: won't help much in certain escenarios
<rvba> roaksoax: yeah, but we definitely need to fix the file storage stuff in MAAS.
<roaksoax> rvba: but this is definitelly cool! we were just talking about it yesterday :)
<roaksoax> rvba: alright. Is there an ETA on when we can start seeing these changes landing?
<rvba> roaksoax: I'd say sometime next week (most of the code is already done).  Because we need to do some serious testing.
<roaksoax> rvba: ok cool
<roaksoax> rvba: btw.. urgency=high is a debian thing, not ubuntu :) (lp:~rvb/maas/packaging.precise.sru-high)
<rvba> roaksoax: haha :)
<Jon___> Howdy, anyone home?
<rvba> roaksoax: btw, please have a look at bug 1131296
<ubot5> bug 1131296 in maas-enlist (Ubuntu) "maas-enlist uses a wrong url when enlisting nodes (/MAAS/api/1.0/nodes//MAAS/api/1.0/nodes/)" [Undecided,New] https://launchpad.net/bugs/1131296
<roaksoax> rvba: will do
<roaksoax> rvba: could you provide a bit more backgroun though?
<rvba> roaksoax: I think the way maas-enlist builds the url it uses to register nodes has a bug.
<rvba> roaksoax: but because of a bug in MAAS itself, it works ok :).
<rvba> The thing is: the bug in MAAS must be resolved.
<roaksoax> rvba: for sure... I wonder what is that is being given to maas-nlist
<roaksoax> rvba: as in maas-enlist -s X.y.z.a/
<roaksoax> or what
<racedo> hey roaksoax we have seen a pattern that when we "release" an allocated node in maas to be ready and then redeploy it after rebooting it goes to grup rescue
<racedo> if we instead delete it, reenlist it and deploy something it works
<racedo> s/grup/grub/
<roaksoax> racedo: how do you release it and how do you reboot it?
<roaksoax> racedo: it seems that on the reboot it is not being told to PXE boot! which is what maas tells the node to do when it tells it to start
<roaksoax> racedo: so if you are manually rebooting the node, it won't pxe boot unless you tell it so via IPMI
<racedo> roaksoax: we reboot it via ipmi
<roaksoax> racedo: manually?
<racedo> yes
<racedo> we dont have ilo or access now
<roaksoax> racedo: that's the problem then
<roaksoax> racedo: if you reboot manually you need to tell ipmi to PXE boot
<racedo> so the sequence is: enlist->commission->deploy then juju-destroy then deploy with constraints maas-name to a node then after reboot it goes to grub rescue
<racedo> roaksoax: ack
<roaksoax> racedo: so
<roaksoax> ipmi-chassis-config ${driver_option} -h ${power_address} -u ${power_user} -p ${power_pass} --commit --filename ${config}
<roaksoax> ipmipower ${driver_option} -h ${power_address} -u ${power_user} -p ${power_pass} --cycle --on-if-off
<roaksoax> where config is: http://paste.ubuntu.com/1700983/
<racedo> yep Boot_Device PXE
<racedo> got that
<racedo> thanks roaksoax that could be it
<racedo> we are confirming it right now
<negronjl> roaksoax, I have a question re: preseed when you get a chance
<roaksoax> negronjl: shoot :)
<negronjl> roaksoax, I see this line in /usr/share/maas/preseeds/preseed_master: partman/early_command string debconf-set partman-auto/disk `list-devices disk | head -n1`
<negronjl> roaksoax, however, when I have seen that line in the past, I have seen it as: partman/early_command string debconf-set partman-auto/disk "$(list-devices disk | head -n1)"
<negronjl> roaksoax, will the above affect anything ?
<roaksoax> negronjl: uhmmm I wouldn't know really
<roaksoax> i don't think it should
<roaksoax> negronjl: depends on the busybox shell I guess
<roaksoax> with i believe is postfix
<negronjl> roaksoax, If I change the preseed file, do I need to restart any particular service ?
<negronjl> roaksoax, I mean if i change /usr/share/maas/preseeds/preseed_master BTW
<roaksoax> negronjl: no, the preseeds anre rendedred at exec time
<negronjl> roaksoax, ack ... thanks
<racedo> we are getting a "No authorization header received." at the last stage of cloud init during commissioning when the nodes are accessing the maas server
<racedo> that prevents them from reporting back to the maas server and go to ready state and they are stuck at commissioning
<racedo> any clue?
<racedo> the address the nodes are trying to contact is http://maas/MAAS/metadata/2012-03-01/
<roaksoax> racedo: the DEFAULT_MAAS_URL is incorrect
<racedo> roaksoax: ok, where is that?
 * racedo checking
<roaksoax> racedo: sudo dpkg-reconfigure maas-region-controller and enter either a hostname or ip address that is addresseable from the node's that are commissioning
<roaksoax> racedo: etc/maas/maas_local_settings.py
<racedo> it's the right one
<roaksoax> racedo: so 'maas' is not resolvable
<roaksoax> http://maas/MAAS/metadata/2012-03-01/ --> 'maas' resolves?
<racedo> ok
<racedo> no
<racedo> it's the ip
<racedo> sorry
<racedo> i pasted it for privacy reasons :)
<roaksoax> racedo: ah lol :), so is the address reacheable from the commissioning server?
<roaksoax> racedo: as in the *same* network?
<roaksoax> of the nodes being deployed?
<racedo> if I access from my browser it says "No authorization header received."
<racedo> yes, they enlist, then reboot then we accept and commission
<racedo> then after cloud init we see that they want to report back to maas using that URL
<racedo> and then they get the auth error 401
<racedo> and get stuck in commissioning
<racedo> instead of going to ready and shut down
<racedo> they just shut down
<roaksoax> racedo: if you access throught the browser you wont see anything because the commissioning steps does authentication
<racedo> ok
<roaksoax> racedo: maybe ntp issue?
<roaksoax> the clocks in the maas server and the nodes are not the same?
<racedo> i ssh to it during comissiong and check the date and it was fine, we went to the bios to set the right time and date too
<racedo> we just rebooted maas and are trying again
<roaksoax> ack
<racedo> roaksoax: i'm going to share a screenshot in a sec if that's ok
<roaksoax> racedo: sure
<racedo> roaksoax: https://docs.google.com/a/canonical.com/file/d/0BzitEgbYskgzN0Y3X21td0RKMU0/edit?usp=sharing
<racedo> you sho
<racedo> should have access :)
<roaksoax> racedo: yeah that's an issue with oath clocks not being synced
<roaksoax> smoser: ^^
<racedo> LP 978127 ?
<ubot5> Launchpad bug 978127 in MAAS "incorrect time on node causes failed oauth" [Critical,Fix released] https://launchpad.net/bugs/978127
<roaksoax> racedo: that seems to be the one
<roaksoax> racedo: you guys are using stable ppa right?
<roaksoax> smoser: was the fix for this backported to maas/1.2?
<smoser> roaksoax, that bug (and its fix) are displayed there correctly.
<racedo> during commissioning i'm sshing the node and the time it's right, it was 5 hours ahead this morning but not now
<racedo> roaksoax: yeah we use /stable
<smoser> racedo, and that system is 5 hours off the clock on the maas server
<racedo> smoser: it was
<racedo> not any more
<smoser> it was in that screenshot
<smoser> thats what its telling you.
<smoser> unless you're telling me you fixed it since that screen shot.
<smoser> but the INTERNAL SERVER ERROR is different.
<racedo> smoser: no, i ssh during comissioning and the time is right, i did right during the time we took the screenshot
<roaksoax> racedo: also please pastebin apache2's error log
<smoser> i suspect you have something in your maas logs
<racedo> ok
<roaksoax> racedo: is the MAAS server with the same time too?
<racedo> yeah
<smoser> racedo, that system and the maas server disagree on the time. by 18000 seconds.
<smoser> theres little doubt in my mind on that.
<smoser> 'date --utc'
<smoser> on both
<racedo> ok
<smoser> i think you have differing clocks, but i dont think thats the whole issue. the fact that the client is re-setting its clock indicates that its working around the issue.
<negronjl> roaksoax, smoser: apache log with errors here: https://pastebin.canonical.com/85324/
<smoser> negronjl, /var/log/apache2/errors.log
<smoser> or something to that effect.
<smoser> you're shoing me access log (i htink)
<racedo> smoser: roaksoax https://pastebin.canonical.com/85326/
<racedo> check lines 4 and 50
<smoser> right. its 5 hours off.
<roaksoax> racedo: Thu Feb 21 20:43:44 UTC 2013 commissioning node: Thu Feb 21 15:43:42 UTC 2013
<negronjl> smoser: https://pastebin.canonical.com/85327/
<roaksoax> times are different
<smoser> (isnt that what i said?)
<racedo> oh!
<roaksoax> racedo: that's your issue
<smoser> its not the issue.
<racedo>  i was being too slow with date then :)
<smoser> unless its causing fallout from maas/longpoll
<roaksoax> smoser: i think txlongpoll is just for UI related stuff isn't it?
<smoser> i dont know. but the error in the screenshot says INTERNAL ERROR
<smoser> and the log says INTERNAL ERROR
<roaksoax> negronjl: restart maas-txlongpoll
<negronjl> roaksoax, done
<roaksoax> smoser: maybe it is related... though I think we saw that too lkast time on the drill
<roaksoax> negronjl: so there's 2 things it seems. 1. the clock skew, 2. txlongpoll
<negronjl> roaksoax, checking the txlongpoll on logs to see if it is still there
<racedo> roaksoax: but the time in the maas server is set to EST even if the BIOS has UTC, is that an issue?
<racedo> roaksoax: https://pastebin.canonical.com/85328/
<smoser> racedo, in ubuntu bios clock always has utc.
<smoser> (i thikn there are some cases where if you're dual booting it will try to not use utc, but you want utc)
<racedo> smoser: should i go to the BIOS and change it to match EST
<racedo> ?
<smoser> that is fine. all checking is done on actual time.
<racedo> ok
<smoser> you want bios set to utc. on both boxes.
<racedo> smoser: we changed it in the BIOS of the commissioning node just in case, then we are changing it back to UTC
 * roaksoax brb
<smoser> racedo, fwiw, i'm pretty sure you could just run 'sudo ntpdate pool.ntp.org' and reboot. and i think that will get it fixed.
<smoser> (because on system shutdown, the current clock is copied to bios clock)
<racedo> smoser: thats right
<racedo> smoser: ok done
<smoser> that will likely fix the oauth complaints, but i think you'll still see the internal server error.
<racedo> smoser: you are right, now it only says internal server error
<racedo> this is what i see in the maas apache error from that client when commissioning: https://pastebin.canonical.com/85331/
<smoser> roaksoax, how do we get more info on that ?
<negronjl> smoser, roaksoax: increasing the debug level in apache ...
<smoser> not apache.
<smoser> maybe in maas.
<smoser> i'm pretty sure its comoing from maas.
<negronjl> smoser: ok
<smoser> we should be able to get a maas stack trace some where.
<roaksoax> maas.log
<roaksoax> celery logas
<roaksoax> and txlongpoll logs
<roaksoax> racedo pastebin those please
<racedo> roaksoax: https://pastebin.canonical.com/85334/ is maas.log
<racedo> after increasing the apache log to debug nothing changed from above apache2 access log
<racedo> the 500 errors are logged in the access log rather than the error log
<roaksoax> racedo did you guys crrate any tags? that error is weird in maas.log
<racedo> roaksoax: no
<racedo> roaksoax: we created constraints
<racedo> and actually we are not getting the maas-name constraint to match the nodes names
<roaksoax> maybe thats related
<roaksoax> i have little to no knowledge in the constraints system
<racedo> now there's no zookeeper
<racedo> no constraints, just maas
<racedo> we can reinstall maas :)
<roaksoax> will need to check logs to see ig any upstream commit might havre regressed something
<roaksoax> could you file a bug with that error log?
<racedo> yes
<racedo> roaksoax: https://bugs.launchpad.net/maas/+bug/1131418
<ubot5> Launchpad bug 1131418 in MAAS "Nodes don't go to ready, after commissioning they get a 500 error when reporting back to maas" [Undecided,New]
<racedo> roaksoax: as we need to finish this, we may reinstall maas now and do exactly the same steps we were following
<roaksoax> racedo: ok i' testing this in my local virtual environment
<racedo> roaksoax: I'm sharing a doc with you of the exact steps we took from the very beginning
<racedo> roaksoax: i shared with you a dump of all the http traffic between the client and the maas server to debug with wireshark if that helps
<roaksoax> racedo: ack thanks
<roaksoax> racedo: still around?
<racedo> roaksoax: yes
<roaksoax> racedo: i don't think this is needed: juju set-constraints maas-name=
<roaksoax> not anymore with newer maas
<racedo> oh ok
<racedo> but doesn't the constraint stay until wiped?
<roaksoax> racedo: nah, the reason why that was done was because there was a bug , but IIRC that was fixed
<roaksoax> racedo: juju add-unit --constraints doens'yt work
<roaksoax> ?
<racedo> roaksoax: what we were doing is specify every time what node we are deploying the server to
<racedo> oh
<racedo> i see what you mean
<racedo> ok, thanks roaksoax
<negronjl> roaksoax, didn't know that add-unit took constraints ... that saves us time
<roaksoax> negronjl: I think that works
<negronjl> roaksoax, not according to the juju help but, I'll give it a try anyway
<roaksoax> let me check
<negronjl> roaksoax, thx
<roaksoax> negronjl: yeah it doesn't :(
<roaksoax> i thought it did
<negronjl> roaksoax, thx
<roaksoax> racedo: so yeah after deploying swift you have to clean the constraints
<roaksoax> becuase you are setting them globally
<roaksoax> but in cases like the bootstrap I think you have tro
<roaksoax> because you only set them for that deployment in particular
<roaksoax> racedo: ok just tested commissioning with latest from maas-maintainers/stable and it commissioned just fine
<racedo> ok, with constraints and stuff?
<roaksoax> racedo: i'm testing that now
<racedo> cool thx
<roaksoax> racedo: ok bootstrap with constraint went fine. I commissioned nodes after bootstrap, also went fine
<racedo> ok, juan is doing it as well here in parallel
 * roaksoax waitingf for the bootstrap to finish
#maas 2013-02-22
<racedo> roaksoax: we are going to keep working from the hotel now
<racedo> catch you later
<roaksoax> alright!
<eazel7> hi =)
<eazel7> how do I provision a new node for maas? can I create VM with libvirt and "enlist" it as a node?
<njin> hallo, it is expected that today's build show 'It Works' message instead maas interface ? thanks
<roaksoax> rvba: howdy!!
<roaksoax> njin: maybe you are missing the /MAAS ?
<rvba> roaksoax: Hi
<roaksoax> rvba: so I tested the django thing... seems to be working just fine
<roaksoax> rvba: have you been able to test it too?
<rvba> roaksoax: yeah, all fine.  Tested on precise and quantal.
<njin> roaksoax, with /MAAS it return error 200
<roaksoax> rvba: cool then i'll move that to /stable
<roaksoax> njin: check your apache2 logs? and maas logs?
<njin> roaksoax, thanks apache2 log is full of errors /usr/share/maas/start_up...Lock timeout, missed mod_wgsi and others
<racedo> rvba: thanks for looking at lp 1131418
<ubot5> Launchpad bug 1131418 in MAAS "Nodes don't go to ready, after commissioning they get a 500 error when reporting back to maas" [Critical,Triaged] https://launchpad.net/bugs/1131418
<racedo> we reinstalled everything last night as we were onsite and had to finish a delivery
<rvba> racedo: np.  As I said on the bug, I suspect the tag definition is buggy.
<racedo> we don't seem to be hitting this after reproducing exactly the same environment two times
<rvba> That's very weird.
<racedo> yes, it all started when using --constraint maas-name=name-of-the-host wasn't recognising the host and the juju log in zookeeper said no such name or no matching or something similar
<racedo> with a name-of-the-host that existed
<racedo> if we see anything today we'll update the lp
<rvba> Ok, cool.
<racedo> roaksoax:  melmoth: have you seen in your engagements maas nodes rebooting after being deployed with a service or even after being commissioned and go to grub rescue prompt?
<melmoth> racedo, not really, but i never understood the powermanagement thingy woith maas
<melmoth> i guess when you deploy a service, it pick a ready node, and boots ip automatically
<melmoth> i never experienced it, but i guess this is what should happen, right ?
<roaksoax> racedo: never
<racedo> roaksoax: melmoth: it's exactly what Destreyf explains here at 19:20: http://irclogs.ubuntu.com/2012/05/15/%23juju.txt
<melmoth> i wont have time to read today.
<racedo> we reported the pattern in lp 1131737
<ubot5> Launchpad bug 1131737 in MAAS "Nodes stay at grub rescue prompt after being redeployed with juju" [Undecided,New] https://launchpad.net/bugs/1131737
<roaksoax> racedo: can you pastebin the celery logs?
<roaksoax> var/log/maas/celery.log region-celery.log
<roaksoax> racedo: what it looks to me is that when you tell it to deploy again it is not actually telling it to PXE boot
<racedo> roaksoax: it picks a pxe image and the cfg says to boot from the disk apparently
<racedo> thats what we understand from the boot screen
<racedo> the funny thing is that it doesn't happen always
 * racedo working on getting the logs
<roaksoax> racedo: might it be that when you juju destroy and then juju deploy to that machine, it is not being set to use the PXE image to deploy?
<racedo> roaksoax: https://pastebin.canonical.com/85444/ celety.log
<roaksoax> rvba: ^^
<racedo> roaksoax: well, but the last pattern was: delete zookeeper from maas, reboot, enlist, accept and commission, node reboots fine, juju bootstrap to node, bootstraps fine, reboots after it finishes, pxe boots, gets pxe config that tells to boot from disk, goes to grub rescue
<roaksoax> racedo: ahh I see
<roaksoax> racedo: so that's a grub issue
<roaksoax> it seems
<racedo> roaksoax: it could well be
<roaksoax> racedo: what's the disk it should be booting from?
<racedo> the funny thing is that it's kind of random
<roaksoax> racedo: do you happen to know what it is been told by PXE when it tells it to PXE boot?
<roaksoax> say LOCALBOOT 0
<roaksoax> or KERNEL chain.c32
<roaksoax> racedo: ok you are gonna have to do something to test
<racedo> roaksoax: we have 4 disks, 3 in raid 5 and one as spare disk, hw raid
<roaksoax> racedo: right, so maybe that's the problem
<roaksoax> but since this is HW raid
<roaksoax> it should
<roaksoax> not affect
<racedo> they are presented as 1 disk to the os
<racedo> ok
<roaksoax> racedo: ok so go to /usr/share/pyshared/provisioningserver/pxe
<racedo> roaksoax: ok, we will test that if we hit it this time (rebuilding)
<roaksoax> racedo: ok, but go there
<racedo> yep
<roaksoax> racedo: you will find 2 files of interest
<roaksoax> config.local.template
<roaksoax> config.local.x86.template
<roaksoax> you need to figure out which one it is using
<racedo> ok
<racedo> oh i see
<roaksoax> i'm guessing it is using config.local.x86.template since that should be used for most of the hw
<racedo> ok, once i figure which one what do i do
<roaksoax> racedo: something like this: http://paste.ubuntu.com/5555710/
<roaksoax> racedo: so LOCALBOOT -1 if it is the one been used
<roaksoax> racedo: or APPEND hd0 or APPEND hd0,1
<racedo> perfect
<racedo> Im documenting this now
<racedo> thanks roaksoax
<roaksoax> racedo: the latter APPEND hd0 is basically telling it boot for hd0
<roaksoax> or boot from hd0,1
<roaksoax> that *might* be the issue
<racedo> got you
<roaksoax> racedo: if this doesn'y solve it, maybe grub messed things up
<roaksoax> racedo: but someone who might help in grub related stuff if cjwatson
<roaksoax> rvba: this is a weird thing: https://pastebin.canonical.com/85444/ (omshell issues)
<racedo> i've seen it over and over ^^
<roaksoax> racedo: did it work? the boot thing?
<racedo> roaksoax: we haven't hit it again, it's 10 nodes so far and nothing
<racedo> roaksoax: it's very random... but i fully agree with you it looks like a grub issue with their hw raid setup
<racedo> roaksoax: we are hitting the issue right now
<racedo> we are at the grub rescue prompt
<racedo> we don't really now how to deal with the grub rescue prompt but negronjl is changing the what you suggested in maas: http://paste.ubuntu.com/5555710/
<negronjl> roaksoax, where ( in the maas server ) are the files that need modifying ... I want to try changing that
<racedo> roaksoax: we got it /usr/share/pyshared/provisioningserver/pxe
<roaksoax> yeah
<roaksoax> sorry
<roaksoax> racedo: so do that andjust reboot the machine manually and tell it to PXE boot
<racedo> roaksoax: ok, we are on it now, just modified the grub templates and we are going to pxe boot a node that fails
<roaksoax> cool
<roaksoax> racedo: try to see what the ouput of the PXE boot says
<racedo> we will see it
<racedo> roaksoax: when you say to tell it to pxe boot
<roaksoax> racedo: ipmi
<racedo> do you mean by ipmi pxe boot it, not reenlist it and start again? will pxeboot apply the new grub commands just by rebooting?
<roaksoax> racedo: yes
<roaksoax> racedo: so you need to do what I told you yesterday
<racedo> yes
<racedo> we got that scripted :)
<roaksoax> cool
<racedo> roaksoax: does this mean that every time a node pxe boots grub get installed through these templates then?
<roaksoax> racedo: nope, this means that when the node PXE boot, it is telling the node "boot from your localdisk, rather than tftp"
<roaksoax> racedo: so chainc.32 should have automatically determined where to pxe boot from, but since it didn't, we are telling it to specifically look for hd0 to pxe from
<racedo> oh, yes but that's happening i think, and then it will go to grub rescue when trying to boot from the disk
<racedo> we are trying to grab a screenshot
<roaksoax> racedo: ok cool
<roaksoax> racedo: or you can do a video
<roaksoax> racedo: with recordmydesktop
<racedo> only our customer has the access from a windows desktop :(
<roaksoax> racedo: boomer
<racedo> yep
<roaksoax> yeah just try to get screenshots
<roaksoax> racedo: did you check with cjwatson?
<racedo> not yet, so we have a plan b if this fails, we have like 2 hours to get this working, the plan is to work with the customer remotely on this if needed
<racedo> but today we have a plan b which is to just not use these boxes
<roaksoax> ack
<racedo> roaksoax: we couldn't catch the screen but i saw: SAY Booting under MAAS direction.. which seems to be on config.install.template
<racedo> but as we deleted it and started again it might be part of this randomness...
<roaksoax> racedo: yeah that's installation
<roaksoax> or ocmmissioning
<roaksoax> racedo: how are things going?
<racedo> roaksoax: we deployed everything with what we had up and running and we might try to debug with the customer and support the grub issue next week if the customer has the time
<racedo> roaksoax: thanks again man, it's been an interesting  week ;)
<racedo> roaksoax: btw if you are interested i captured the tcpdump of yesterday's internal server error and today extracted the xml file that the node posts to maas with wireshark: https://launchpadlibrarian.net/132080481/maas_xml_post
<racedo> this is lp 1131418
<ubot5> Launchpad bug 1131418 in MAAS "Nodes don't go to ready, after commissioning they get a 500 error when reporting back to maas" [Critical,Triaged] https://launchpad.net/bugs/1131418
<roy-feldman> I have found a bug on the MAAS site. Should I report it on the Ubuntu Issue tracker? I ask because it is actually not a bug with a Ubuntu distro.
<roy-feldman> Basically, the search feature for the online documentation is broken. It simply hangs when you do  a search.
<roy-feldman> Search works on the rest of the MAAS site.
<roy-feldman> But searches on other parts of the MAAS site don't seem to report matches in the MAAS docs.
#maas 2014-02-17
<bradm> are there any decent docs about how to write preseed files and modify them for maas?
<bigjools> bradm: it's not a maas-specific thing really
<bigjools> https://help.ubuntu.com/12.04/installation-guide/i386/preseed-intro.html
<bradm> bigjools: I'm talking about what you can do inside the {{ }} tags
<bigjools> that's a templating language called Tempita:  http://pythonpaste.org/tempita/
<bigjools> http://pythonpaste.org/tempita/#the-language specifically
<bradm> bigjools: and how do we know what variables we have access to in there? apparently I want to access node.tags.all(), but how would I find that out?
<bigjools> reading the code, it's not documented :(
<bradm> I think what I want is {{ if 'nova-compute' in node.tags.all() }}
<bradm> but its a guess based on the examples
<bigjools> should work
<bradm> cool, thanks
<bradm> is there any way to either see the preseed that's used by maas for a node, or maybe to capture the output from syslog of the install?
<bigjools> bradm: yeah there's a preview on the node page
<bradm> bigjools: aha, sweet.
<bradm> oh, haha, thats what happens when you make assumptions about tag names
 * bigjools gets annoyed with whatever is stealing the ctrl-space shortcut on the desktop
<bigjools> no, I don't ever want to change my keyboard layout once I set it, Unity
<roaksoax> bigjools: howdy!! so maas was broken in latest trunk and nobody noticed
<roaksoax> :)
<roaksoax> bigjools: fixes were really packaging branch but if I hadn't tested, nobody would have noticed :)
<bradm> ugh, debugging preseeds is time consuming
<roaksoax> bigjools: so something changed on how maas binds ports? or how pserv does? cause now I had to use authbind for pserv too when before wasn't needed
<roaksoax> bigjools: uploaded!
<bradm> bigjools: any hints on what else it could be to match a tag?  if "compute" in node.tags.all() doesn't seem to do it
<bradm> ah, node.tags.all() is empty in the preseed
<bradm> and the node definately has a tag
<bradm> do I need to be using the curtin installer or something?
<bigjools> roaksoax: it's a *really* good idea to wait for a successful qa lab run before uploading anything
<bigjools> bradm: it will be returning tag records, not tags, so it will need something like:
<bigjools> tag.name for tag in node.tags.all()
<bigjools> you might need :py mode, but see if it works
<bradm> bigjools: can I assign that to a variable or something?
<bigjools> yeah use a define block
<bradm> bigjools: so a python define block to create a function?  like {{py: def tagsname(n): return tag.name for tag in node.tags.all() }} or something?
<bigjools> no
<bigjools> hang on
<bradm> bigjools: or the {{def tagsname}} stuff?
<bigjools> bradm: http://pythonpaste.org/tempita/#inherit-def
<bigjools> you can set python vars as well
<bradm> bigjools: hmm, I'll play about with it and see what I can do
<bradm> bigjools: I think this is a really important idiom for tweaking preseeds based on tags
<bigjools> bradm: yes, sounds reasonable
<bradm> bigjools: clearly I suck at this :)
<bradm> https://pastebin.canonical.com/104959/ prints out the tags on from the node
<bigjools> use public pastebin if you can
<bigjools> but glad it worked for you
<bradm> yeah, just need to figure out how to turn that into an if statement now
<bigjools> {{py: if "mytag" in [tag.name for tag in node.tags.all()] }}
<bradm> bigjools: https://pastebin.canonical.com/104960/
<bigjools> use public pastebin if you can
<bigjools> please
<bradm> oh, bah
<bradm> http://pastebin.ubuntu.com/6947342/ - gives me a function I can use later like - if 'mytag' in tagnames(node)
<bradm> bigjools: hrm, yours doesn't work for me
<bigjools> it was untested :)
<bigjools> if yours works then fine
<bradm> yours is nicer in terms of using less space
<bradm> http://pastebin.ubuntu.com/6947349/ <- what I'm trying to do - I can have different late_commands based on tags
<bradm> I suspect its the endif etc thats there
<bradm> bigjools: thanks for the help, this should work out nicely
<bigjools> bradm: np
<bradm> I don't like maintaining multiple sets of data with most of it duplicated, this will fix that
 * jtv just wasted a few hours trying to get his escaping test for a data display working, only to realise the data got neatly un-escaped as part of the extraction from HTML in the test itself.
<rvba> I'm still getting 'AttributeError: class Factory has no attribute 'forProtocol'' when running 'make run+webapp' on trunk. (http://paste.ubuntu.com/6947733/)
<rvba> Anyone else seeing this?
<rvba> bigjools: btw, about lp:~julian-edwards/maas/default-commissioning-series : we're now using Trusty for commissioning but we're still importing *all* the images.  This is such a waste of bandwidth!
<jtv> Should be an easy fix!
<rvba> bigjools: fixing this will reduce the time it takes to import the images.
<bigjools> rvba: +1!
<bigjools> silly omission
<bigjools> although we may need some more for deployment to other releases
<rvba> bigjools: we need to keep all the deployment images indeed.  But the ephemerals take much longer to import.
<bigjools> yes
<jtv> rvba: I've pushed a change that tests for, and fixes, the QuerySet nastiness.
<rvba> jtv: cool, branch approved.
<jtv> Thanks!
<rvba> jtv: forgot to say, you might want to rename NetworkConnectNodesForm to re-use it verbatim in the method used to remove nodes.
<jtv> Might, yes...  small tweak to the help string I guess.
<rvba> Right.
<jtv> rvba, want to try this one?  https://code.launchpad.net/~jtv/maas/sample-commissioning-data/+merge/206711
<rvba> jtv: sure
<tomixxx3> hi, does it make sense to set "ip address" equal to "router ip" in maas dashboard?
<jtv> Hi tomixxx3.  I think it does, if your maas server is also your gateway.  But we don't really do anything with router_ip; it's just there so you can allocate nodes that are connected to a particular router.
<tomixxx3> k i will try - and change it also in "interfaces"
<tomixxx3> do i have to re-commission nodes after a change like this?
<jtv> Which are you changing?  IP address of a cluster interface?
<tomixxx3> no, gateway address of the network interface
<jtv> Gateway address is different from router_ip...  The gateway is configuration for MAAS's DHCP server.
<jtv> Basically, that's "when I serve DHCP to a node, where should I tell the node its gateway is?"
<jtv> If you're not managing DHCP on any interfaces, it's not going to matter.
<tomixxx3> puhh... ok, whre can i set the gateway-address then?
<jtv> On the DHCP server.  Are you running your own DHCP server for the nodes, or are you letting MAAS serve DHCP?
<tomixxx3> MAAS runs DHCP + DNS for the nodes
<jtv> Ah OK
<jtv> In that case you do need the gateway setting on the cluster interface.
<jtv> I don't think you need re-commissioning after a change like that, per se, but the nodes may still have old information.
<tomixxx3> k, i should maybe reboot nodes then
<jtv> That would make them pick up the settings, yes.
<tomixxx3> now is the question what is the gateway address
<jtv> Whatever gateway the nodes should use when communicating to the internet.
<tomixxx3> my maas server has 2 interfaces. is it the ip of the interface which connects the maas-server to internet?
<tomixxx3> would make sense, not? ^^
<jtv> Slightly different:
<jtv> the gateway setting tells DHCP clients: "if you have a packet that you want to send to a host that's not on the same network, send it to the gateway and it will forward your packet."
<jtv> So if your maas server is also the gateway between the nodes and the internet, it should be the IP address of the interface that the nodes can see.
<jtv> (I hope.  Rusty!)
<tomixxx3> hmm, i have set the gateway equal to ip address, but now my maas-server lost its i-net connection
<jtv> The _server_?
<jtv> The gateway setting will only affect the nodes.
<tomixxx3> yes...
<tomixxx3> i swear
<tomixxx3> its the server
<jtv> Are you sure you edited the cluster interface where you serve DHCP?
<jtv> Or it could simply be unrelated...
<tomixxx3> i have changed "interfaces" file and i have changed cluster interface settings in maas dashboard
<jtv> Ah, then your interfaces file may be broken.
<jtv> You could try running "sudo ifup <interface>" in a shell (where <interface> is e.g. eth0 or eth1)
<jtv> Just to see if there's an error...
<tomixxx3> ifup, ifdown works
<jtv> Hmmm
<tomixxx3> i dont understand this
<jtv> Neither do I!
<tomixxx3> i could try the ip of the other interface card as gateway
<jtv> Well... gateway setting shouldn't affect the server itself.  Something else is wrong.
<jtv> And it sounds as if it's in the system network settings, really, not the MAAS settings.
<tomixxx3> server is reachable through 10.0.0.9/MAAS only i-net does not work
<jtv> So... the nodes can reach the server and vice versa, but the server cannot reach the internet?
<tomixxx3> yes
<jtv> And that interface gets its IP address from the uni's DHCP server, right?
<tomixxx3> yes
<jtv> Does it have one now?  Is the interface up?
<tomixxx3> yes
<jtv> Can the server reach other hosts on the university network?
<tomixxx3> just a moment, iam rebooting the server right now - and i have forgotten to run the NAT-script...
<tomixxx3> its a NAT script provided by gmb
<jtv> Yes, I remember.
<jtv> I hope you don't have one of those weird setups where on some boots, eth0 and eth1 are switched around...
<jtv> But probably not.
<tomixxx3> hehe, i have tried already inverted ethernet ports in the script :D
<jtv> Hope that didn't affect anything...
<tomixxx3> schould not
<tomixxx3> the server behaves like the nodes now: it can resolve the DNS name of any http-url but it cannot connect...
<jtv> That does sound as if some wires got crossed somewhere...
<tomixxx3> assume my gateway address is 143.205.140.30, the ip of the other network interface
<tomixxx3> what could my ethernet settings look like xP - they should also allow 10.0.0.9 as a IP
<tomixxx3> sorry wrong question. why iam not able to set the "network" parameter in cluster interface settings
<tomixxx3> ?
<jtv> Network parameter?  I don't understand what parameter that is... do you mean netmaks?
<jtv> *netmask?
<tomixxx3> no, i mean "network", the part of the net
<jtv> Ohhh
<jtv> That's not a parameter.
<jtv> That's just a network address computed from your cluster interface's IP address and netmask.
<tomixxx3> ok
<tomixxx3> if i remove the gateway line from the "interfaces" file i have access to i-net on server again
<jtv> Oh, did you set your own server's address as its own interface in its own interfaces file!?
<jtv> That would create a fun situation.  :)
<tomixxx3> yes i guess
<tomixxx3> bad?
<jtv> Yes â if you set a gateway in your interfaces file, that tells _that same machine_ where it should send its internet packets.
<tomixxx3> so it asks only itself?
<jtv> As you noticed we have 2 "gateway" settings.
<jtv> One is in /etc/network/interfaces.
<jtv> The other is in MAAS.
<tomixxx3> yep
<jtv> The one in /etc/network/interfaces is for configuring your server's own networking.
<jtv> But the network interface that goes to the "outside" should just get its gateway from DHCP.
<jtv> On the other hand, the gateway setting in MAAS is configuration for the DHCP server.
<jtv> It doesn't do anything for your machine, but the nodes are its DHCP clients.
<jtv> And it tells the _clients_ where their gateway is.
<tomixxx3> ohoh
<jtv> For the clients (your nodes), your server is the gateway.  That's fine.
<jtv> But you configured your server to use itself (on the other interface) as the gateway.
<jtv> And so it was probably just running around in circles.
<tomixxx3> i understand
<tomixxx3> good point
<tomixxx3> so maas takes control over the one ethernet port?
<tomixxx3> wow, this could solve a lot of troubles
<tomixxx3> jtv: but i have to configure the ehternet port in the "interfaces" file too?
<tomixxx3> jtv: just remove the "gateway" to be the same as the ip
 * jtv reads backscroll
<jtv> MAAS doesn't actually take control of any ethernet interfaces.  But it serves DHCP on the interface that faces your nodes, which is pretty bossy.
<tomixxx3> OK, so only the "gateway" line should be replaced in the "interfaces" file?
<jtv> I mean good, but it's more "taking control of the network" than "taking control of the ethernet port."
<jtv> It's hard for me to imagine what the current state is, and it's getting a bit late to really dive into it... but generally, you set up your system's networking in /etc/networks/interfaces, and then you let MAAS run on top of that as basically just another server application.
<jtv> MAAS tries to _detect_ your system setup when you install it, but it doesn't keep track after that and it doesn't change them.
<jtv> It only does that sort of "bossy" stuff on the nodes.
<tomixxx3> kk
<tomixxx3> shit
<tomixxx3> sorry, it seems it is working now!
<tomixxx3> i have removed the "gateway" line from "interfaces" and set "ip router" in dashbaoard to "10.0.0.9" - same address like the IP address of the maaas-server
<jtv> The "IP router" field in MAAS doesn't matter much â that's just for large setups where you sometimes want to allocate nodes that are connected to specific routers.
<tomixxx3> hmmm, or was it the reboot of the nodes?
<tomixxx3> i dont know...
<jtv> Well the incorrect gateway setting in /etc/networks/interfaces you had earlier definitely sounded like a problem.
<tomixxx3> yeah, but before today i had no gateway line configured...
<tomixxx3> executed "wget www.orf.at" from ubuntu@cloud1 now and everything seemts to work "index.html" saved...
<tomixxx3> i cant believe right now, maybe just a fata morgana
<jtv> heh
<jtv> Networking can be tough going, but it's useful knowledge in general life.
<jtv> And when I say "general," obviously I mean "deeply technical computer-related."  :)
<tomixxx3> yeah, quite a good feeling right now, i want to expand my cloud :D *hrhr*
<tomixxx3> jtv: but it's definitely the "router ip" setting
<tomixxx3> if have tried a different value now, and it is not working anymore
<jtv> And if you set it back to the previous value, it works again..?
<tomixxx3> jtv: worth a try
<tomixxx3> what do u mean with previosu value? "ip address" == "router ip" or "ip address" == the address before today?
<tomixxx3> i've tried it with "the address before today" and it does not work
<jtv> I mean, if you reset it to the "good" value that worked just now, it works again?
<tomixxx3> that's what im trying right now
<tomixxx3> would be cool
<tomixxx3> ^^
<jtv> Let's hope it works!
<tomixxx3> yep, working
<jtv> Great!  I don't understand it, but maybe tomorrow I can look into it.
<jtv> For now, I have to leave.
<tomixxx3> kk, ty for help so far!
<jtv> np!
<chris38home__> just upgrade maas on trusty and got this in pserv.log :
<chris38home__> twisted.internet.error.CannotListenError: Couldn't listen on 127.0.0.1:69: [Errno 2] No such file or directory.
<chris38home__> any idea ?
<bigjools> what version of the package?
<chris38home__> 1.5+bzr1951+1951+243~ppa0~ubuntu14.04.1
<bigjools> you are better off using the main archive for trusty
<chris38home__> go it on 1.5+bzr1951-0ubuntu1 too
<bigjools> the daily build packages may be broken at any time
<bigjools> ok
<bigjools> roaksoax: is that ^^ anything like the authbind error you saw?
<roaksoax> bigjools yup. Still need to handle upgradea. Clean inatalls are not affected
<bigjools> roaksoax: what's the procedure to handle the upgrade so chris38home__ can be unblocked?
<bigjools> and the rest of us :)
<chris38home__> ;-)
<roaksoax> just edit /etc/authbind/byuid/xyz
<roaksoax> and make ghe 68:68 become68:69
<bigjools> right
<chris38home__> cool, got it fixed
<chris38home__> thanks ;-)
#maas 2014-02-18
<roaksoax> bigjools: thoughts? http://pastebin.ubuntu.com/6952628/
<bigjools> roaksoax: you probably have the system python package installed
<bigjools> the wrong one I mean
<roaksoax> bigjools: yeah, a higher version that the one requireD: http://paste.ubuntu.com/6952634/
<roaksoax> bigjools: ok, it seems a information issue. I didn't have daemontools installed and it complained about python-amqplib it seems
<bigjools> roaksoax:  which branch is this?  amqplib is not in trunk
<roaksoax> bigjools: this is trusty trunk on saucy
<bigjools> oh it won't work on saucy
<roaksoax> bigjools: yeah can see that now
<bigjools> :)
<roaksoax> bigjools: anyway, I guess I'll fix the test in question tomorrow then
<roaksoax> bigjools: anyway, ttyl!
<bigjools> roaksoax: cheers!
<jtv> roaksoax: I'm just landing a UI for showing the commissioning results that we have in the database.
<jtv> It's not great, but I couldn't take the lack of visibility any more.  :)
<jtv> Look for a link at the bottom of a node's details page.
<jtv> I do wish we could link from documentation straight to specific methods in the API documentation.
<jtv> bigjools: last planned branch for the Advanced Networking lane is up for review.
<bigjools> jtv: sweet
<bigjools> jtv: api docs need anchors, you mean?
<jtv> Yup.
<jtv> And/or a big notice about what those anchors are.  :)
<bigjools> jtv: "connecting a node and a network that are not connected is not an error"
<bigjools> don't understand
<bigjools> as in, literally, I don't know what you mean by this
<jtv> Oops.  That should be disconnecting.
<jtv> Typo.
<bigjools> ah!
<bigjools> jtv: while you're at it
<bigjools> jtv: in the preceding sentence that starts with "Or", the comma after "network" should be after the "Or"
<bigjools> or, don't start a sentence with "or"
<bigjools> :)
<jtv> And while you're at it: https://code.launchpad.net/~jtv/maas-test/typo-2014-02-18/+merge/206851
<bigjools> heh, done
<jtv> Thanks.  Ah, I see now: it was a typo the other way around.  I typed "not" when I meant "already."
<jtv> So: connecting a node and a network that are already connected is not an error.
<bigjools> jtv: can I do a super quick pre-imp
<jtv> bigjools: sure, modulo my laptop's boot time.
<bigjools> jtv: call away when ready
<jtv> Mind if I get coffee too?
<bigjools> jtv: no, actually can you hang on, I need to make a quick call
<jtv> OK
<jtv> Had some trouble logging in again, but it's working now...
<bigjools> jtv: we should have had a call anyway, oops sorry.  hang on, on hold here
<jtv> No, that's tomorrow.  Want to do your pre-imp tomorrow? :-)
<bigjools> jtv: oh heck :)
<bigjools> calling you now
<jtv> rvba: one thing I really miss is an ability to link from documentation straight to individual API calls (or handlers).
<rvba> jtv: that's a good point.  We could add anchors for every method.
<rvba> s/every method/all the methods/
<jtv> For all I know they might already exist...
 * jtv wonders why the maas-enlist package has a maas-commission.install
<rvba> jtv: they do not exist: https://maas.ubuntu.com/docs/api.html
<jtv> Then they should.  :)
<jtv> Wonder why that page is not loading at the moment...
<jtv> Ah here it comes
<jtv> Yup.  No anchors.  Not even any id attributes that we could use as of HTML5.
<rvba> This page could be improved.  All the information is there but it's a bit difficult to follow because it's not greatly formatted.
<jtv> Yes, it's pretty ugly â hard to see what the structure is.
<rvba> Indeed.
<jtv> We could get a lot of improvement out of just generating headers for the handler classes, I think.
<jtv> With anchors, obviously.
<rvba> Like you said earlier, I think we want anchors for every single method.
<jtv> Yes, that would be even better.
<jtv> But ideally I'd want both.
<rvba> Agreed.
<gmb> rvba: Do you remember how to fix "RuntimeError: Timed out waiting for dnsmasq lease for 52:54:00:f1:4d:cd." when running maas-test? It's happening all the time now on canonistack.
<gmb> ISTR we ran into this way back when.
<rvba> gmb: sorry, I don't remember (I don't even remember seeing this error).
<gmb> Gnargh.
 * gmb tries bouncing libvirt
<rbasak> gmb: that error's from uvtool. uvt-kvm is waiting for the MAC address of the VM to appear in /var/lib/libvirt/dnsmasq/default.leases so that it can pick up its IP
<rbasak> gmb: I'm interested to know if the issue is that the timeout is too short, or if something has changed to cause it to never work.
<gmb> rbasak: Okay. Anything I can do to aid debugging?
<rbasak> gmb: a few things I guess, if you want to work with me?
<rbasak> gmb: first, can you pastebin "virsh dumpxml <machine-name>"?
<rbasak> gmb: "virsh list" should give you a list of machine names. Perhaps you only have one?
<rbasak> I think maastest uses a UUID or something
<gmb> rbasak: It does. Give me 5 minutes just to wrap up what I'm doing and I'll get started.
<rbasak> gmb: sure
<gmb> rbasak: http://paste.ubuntu.com/6954532/
<rbasak> gmb: does the MAC in the error match the one on line 42?
<jtv> Hi rbasak â I see my problem wasn't a fluke and gmb had the same thing
<rbasak> Next question after that. Does maastest use the --log-console-output option to uvt-kvm?
<gmb> rbasak: Well, no, because the one in the error is an old one; we tear down the VM when m-t finishes (I've hacked it to leave it lying around).
<gmb> rbasak: Not AFAIK; will check.
<rbasak> gmb: while you're there, please add "--password foo" for testing.
<rbasak> gmb: then we can log in on console and examine the VM from the inside
<gmb> rbasak: Okay, on it.
<rbasak> gmb: if you can remove --log-console-output if it's in use (otherwise no worries)
<gmb> rbasak: It isn't. I'll add the --password option
<rbasak> gmb: then, before it's timed out, you should be able to run "virsh console <machine-name>" and see a VT login, and then log in as ubuntu/foo
<gmb> k
<rbasak> From there, I'm interested to know if the VM has an IP on the same range as what dnsmasq on your host listens on (virbr0 interface on the host by default I think)
<rbasak> If it helps, "uvt-kvm wait" takes a --timeout option, which is the number of seconds to wait before timeout.
<gmb> rbasak: Okay, it might be as simple as specifying that, but let me take a look anyway.
<rbasak> Or, you might see through the VT that the VM is taking too long to boot for some reason.
<rbasak> Looks like the default timeout is two minutes
<gmb> rbasak: Right. So, I think the VM is taking too long to boot, and uvt-wait is puking. I'll try upping the timeout; the console was pretty sluggish.
<rbasak> Hmm, OK. I noticed that nested KVM is unusually slow on canonistack. Didn't think it was quite that bad.
<rbasak> Manpages are on the way, BTW. I'll try writing a diagnostics section, too.
<gmb> rbasak: Yeah, we've seen that all the way through m-t developmnet. In fact m-t warns you about trying to run nested KVMs for that reason.
<gmb> rbasak: Brilliant, thanks.
 * rbasak goes afk for a while
<rbasak> gmb: happy to see uvtool being useful. BTW, I have a bunch of changes in trunk that I'll land in universe soon. I don't think it'll break maastest at all, but look out for it.
<rharper> what's the best way to disable pserv.log?
<roaksoax> rharper: why would you want to disable pserv.log?
<rharper> at least the version I have is 99% filled with ACKDatagram when sending data over tftp
<rharper> 2014-02-14 19:33:49+0000 [RemoteOriginReadSession (UDP)] Datagram received from ('10.245.0.130', 49156): <ACKDatagram(blocknum=12844)>
<roaksoax> rharper: that's fixed
<rharper> running: python-maas-provisioningserver   1.4+bzr1693+dfsg-0ubuntu2.2~ctools0 on a precise host
<jtv1> That gets sent to /dev/null by default, I thought...
<roaksoax> rharper: shouldn't show more of that stuff
<roaksoax> rharper: check /etc/maas/pserv.yaml?
<roaksoax> rharper: you can disable it there
<rharper> roadmr: cool, so, unccomment or /dev/null ?
<rharper> err, roaksoax ^^
<roadmr> rharper: hello :)
<rharper> roadmr: sorry; tab completed, meant for roaksoax
<roadmr> rharper: I know, at this point I'm just pulling your leg :)
<rharper> hehe
<roaksoax> rharper: /dev/null IIR
<roaksoax> rharper: /dev/null IIRC
<rharper> thanks
<Guest3232> Hi, when you deploy a service using juju etc, does it run on a single node? Im trying to umderstand the benefit of openstack on maas
<roadmr> Guest3232: a service can have several units, each *unit* runs on a single node (if I understand correctly)
<roadmr> Guest3232: as for openstack and maas, they're two different environments from juju's point of view
<roadmr> Guest3232: if you juju deploy to your maas environment, by default it will deploy each unit on a separate machine
<roadmr> Guest3232: if you juju deploy to the openstack environment, it should deploy each unit to a separate *virtual machine* (depending on how openstack is set up, many VMs may share the same physical machine)
<roadmr> Guest3232: interestingly you can use juju to deploy openstack on a maas cluster, then use the same juju to deploy other services to that openstack cluster (hope I'm not confusing you)
<Guest3232> Lol
<Guest3232> So, with openstack a vm can span several nodes and run applications on it, but with just maas it runs om
<Guest3232> on one machine only? With max resources of amsingle
<Guest3232> *a single machine?
<Guest3232> Im trying to work put the point of openstack if maas already spreads applications over several machines
<roadmr> Guest3232: strictly speaking maas doesn't do that; it's juju doing the deployment on several machines
<roadmr> Guest3232: maas just provides the machines for juju to deploy services
<Guest3232> Ah i see
<roadmr> Guest3232: I guess it depends on what the underlying hardware is
<Guest3232> So at what point is openstack > juju
<roadmr> Guest3232: same thing :) openstack is a "provider" of "machines" for juju to deploy services on
<roadmr> Guest3232: the difference is that maas provides actual bare-metal machines (hence metal as a service) whereas openstack provides virtual machines
<Guest3232> Ah cool, so i could get away with running web services, hadoop etc straight off maas and not bother with openstack?
<Guest3232> If i use juju
<roadmr> Guest3232: and I guess it depends on your hardware and scaling needs. If you have 10 really beefy machines, you can put openstack and juju deploy to openstack, so you can create say hundreds of VMs on your beefy servers and host 100s of units/services
<roadmr> Guest3232: OTOH if you have 1000 lower-powered micro-servers, you could use maas and juju-deploy to that, so each unit gets its own, tiny hardware instance
<Guest3232> Will juju put more than one application on a server if it thinks it can handle it?
<roadmr> Guest3232: You could, yes. I suggest you read up on openstack and what benefits it offers you
<Guest3232> Hmm ok thx
<Guest3232> :)
<roadmr> Guest3232: not unless you tell it to, and moreover, per the juju documentation, charms may not cooperate with each other
<roadmr> Guest3232: "they will happily trample over other charms hosted on the same machine"
<Guest3232> Ok so potentially with just juju, youll under use the full machines power
<roadmr> Guest3232: exactly
<Guest3232> Aaaah
<roadmr> Guest3232: say you juju deploy wordpress and mysql to a maas cluster, each will get their own machine even if they could run on a single one
<Guest3232> Ah i see
<roadmr> Guest3232: for this simple example it's OK, but imagine a complex setup needing 10 different services
<Guest3232> Not ideal
<Guest3232> Ok cool so ill look at openstack
<roadmr> Guest3232: with maas you'd need 10 physical machines
<roadmr> Guest3232: with openstack potentially one would suffice, and 10 VMs would be spun up on that same hardware
<Guest3232> I guess i was hoping to move away from having to keep loads of vms patched etc
<roadmr> Guest3232: bear in mind, though, that openstack *does* require deployment on multiple machines (read the docs!)
<roadmr> Guest3232: I have a toy openstack cluster here and it uses 10 machines
<roadmr> Guest3232: but if the nova-compute node is beefy enough it could potentially host 100 VMs
<roadmr> Guest3232: so see, you can host 100 units which would require 100 machines with maas alone, but using only 10 physical machines
<Guest3232> Yeah ok cool i understand now
<Guest3232> So is there a charn style way to deploy within openstack
<Guest3232> *charm
<Guest3232> Or is it manual creation and setup of an o/s via a new vm
<Guest3232> Then adding httpd, sql etc and setting up the service
<roadmr> Guest3232: oh you can juju deploy to an openstack cluster :)
<roadmr> juju deploy -e openstack wordpress
<roadmr> (assuming you have an openstack environment configured)
<roadmr> Guest3232: I have to go now, sorry, good night!
<Guest3232> Thx later
<bigjools> morning roaksoax
<roaksoax> bigjools: howdy!
#maas 2014-02-19
<rmiguel> hi friends, I have doubts concerning the nodes maas, the documentation does not make clear what procedure to be performed after the MAAS set the IP SERVER, NODE in the installation, after which it shuts the machine automoticatimente and does not proceed to installation of the NODE .
<rmiguel> Grateful for help
<bigjools> rmiguel: hi
<rmiguel> Hi
<bigjools> the node goes through different states:
<bigjools> Starts life as "declared".  When you hit "accept" it will transition to "commissioning" and turns on, does some tests, and shuts off, then goes to "Ready"
<bigjools> When it's in the "Ready" state it will become available as a resource for clients.  When you hit "start" in the UI, or it gets used by Juju, its state changes to "allocated"
<bigjools> at that point an OS is installed
<bigjools> and it reboots after installation
<bigjools> does this help?
<rmiguel> yes, the name is in another virtual machine.  I'm using vmware virtualizer
<rmiguel> *node
<rmiguel> My station node in state commissioning
<rmiguel> my nodes are in state commissioning
<rmiguel> which and the procedure to be done now.
<chris38home__> rmiguel, are you sure they started to run , how do ypu make them  start in the power on config ?
<chris38home__> you have to be sure the wm will net boot on the corntroler node
 * chris38home__ away
<rmiguel> a question which this service dhcp documentation guides to do, is essential for the operation of nodes?
<rmiguel> In my setup it did not set, I'm using my network cards in NAT.
<bigjools> rmiguel: you must have DHCP set up correctly
<bigjools> maas will not work without it
<bigjools> http://maas.ubuntu.com/docs/install.html#configure-dhcp
<rmiguel> OK Bigjools,  I'll make the necessary settings in case you need to ask questions back.
<rmiguel> Thank you for your attention.
<bigjools> rmiguel: no problem
<bigjools> roaksoax: I did an FFE https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881
<ubot5> Launchpad bug 1281881 in MAAS "FFE: maas support for third party hardware drivers" [Critical,Triaged]
<bigjools> jtv: which migration had the vlan tag !null change?
<jtv> I think it was 66, but lemme look.
<bigjools>             ('vlan_tag', self.gf('django.db.models.fields.PositiveSmallIntegerField')(unique=True, null=True, blank=True)),
<jtv> Yup.
<bigjools> so it was applied locally
<jtv> I think what may have happened is:
<bigjools>  vlan_tag    | smallint               | not null
<bigjools> WTF
<jtv> 1. You installed a development version with revision 66, which creates that table.
<jtv> 2. I wrote a migration that made the column nullable.
<jtv> 3. You told me to merge my new migration into migration 66.
<bigjools> I don't use dev versions on this box
<jtv> It could still have produced a daily build, wouldn't it?
<bigjools> oh, yes
<bigjools> quite probably
<bigjools> ok
<jtv> And so you already have schema version 66, but it's the old version of version 66.
<bigjools> ok
<jtv> One feature I would still have loved to add for networks is bulk actions.
<jtv> "Connect all these nodes to network: <network>"
<jtv> "Disconnect all selected nodes from: <network>"
<jtv> Since we know how to do that kind of thing now.
<bigjools> maasdb=# alter table maasserver_network alter column vlan_tag drop not null;
<jtv> Yes, that should do it.
<jtv> Assuming that's the only other change that got merged into that schema migration.
<bigjools> yeah
<jtv> You see why I like to keep those migration steps separate even if it gets messy.
<bigjools> I do
<bigjools> but the damage is limited to daily PPA users
<bigjools> and it's advertised as dangerous to use
<bigjools> so I don't care so much
<jtv> Just a stupid time sink.  Surprising that it still bites you so long after.
<jtv> Daily-build installs probably need regular fresh reinstalls.
<bigjools> jtv: the commissioning script display is excellent work dude
<jtv> Thanks!
<jtv> I was chuffed to bits with Gavin's review, apologetic though he was about it.
<jtv> It really wasn't so nice to look at before that.
<bigjools> I am sending an email with my review of the latest UI work
<roaksoax> bigjools: finally back
<bigjools> roaksoax: long trip!
<roaksoax> bigjools: ok so the maas-enlis change makes sense?
<bigjools> yes
<bigjools> I have another suggestion for you
<roaksoax> shoot
<bigjools> I think we should get rid of the packaging branch and put debian/ in upstream
<bigjools> the silence is deafening :)
<roaksoax> bigjools: nope
<roaksoax> bigjools: :)
<bigjools> is that a "nope, don't do it?"
<roaksoax> bigjools: normally... when upstream ships its own packaging we 1. remove it and provide our own. 2. improve it and remove it from the source and use our improved one
<bigjools> ok
<bigjools> but we are both here :)
<bigjools> ok let me ask this another way
<bigjools> I want to make a simple makefile target, in upstream code, to build a package
<bigjools> the location of the packaging branch becomes an issue
<roaksoax> bigjools: right. So let me think about this becausd we normally w ship both separately regardless of us being upstream (unless policies have changex)
<bigjools> also there's a damn bug in bzr builddeb which makes this a PITA
<roaksoax> bigjools: but im not fully agaisnt it... im just talking with my packager hat
<roaksoax> whats the bug?
<bigjools> otherwise, combining the branches and a bzr db --split would have DTRT
<bigjools> it always looks for upstream tarballs before considering the fact I told it to look for a local branch
<bigjools> I found the code with the bug, considering submitting a patch
<roaksoax> bigjools: how do you build?
<bigjools> I was trying to use:
<roaksoax> i mean whT command?
<bigjools> bzr bd --export-upstream=../mybranch --export-upstream-revision=NNNN --merge
<bigjools> or if debian/ is local you can just use --split
<roaksoax> rright
<bigjools> and it's supposed to create a tarball from the local  branch
<roaksoax> right
<bigjools> but bzrlib/plugins/builddeb/cmds.py at line 417 should be insert, not append
<roaksoax> so i dont have strong objections to it ... but normLly packaging should go outside the code itself
<bigjools> yeah - I don't care honestly, I just want this to work :)
<roaksoax> bigjools: so let me dig into this and i'll get back to you on that. Lets just make this happen post 10.04 if possible
<bigjools> I can *assume* that packaging is always at ../packaging/debian/
<bigjools> for now, anyway
<roaksoax> ok cool
<roaksoax> bigjools: but anyway. ameetp was looking pn major dofferences between 12.04 maas and 14.04 maas... can you put something together?
<bigjools> roaksoax: it's all in the changelogs
<roaksoax> bigjools: he wants major features tho
<bigjools> oh pre-13.10 is not
<bigjools> roaksoax: he can look at LP milestones
<bigjools> it's all there
<roaksoax> ok
<bigjools> roaksoax: btw can you can iscpy packaged before the deadline?  And in main?
<bigjools> it's needed for this command you wanted to run from packaging to insert the forwarders
<roaksoax> bigjools: i thought the forwarders were already being inserted...?
<roaksoax> bigjools: i can try to take care of it tomorrow bit wven if i do is up to a archive admin to review the package and accwpt it in the archives and it might not make it in time
<bigjools> roaksoax: shit
<bigjools> can we file ffe?
<bigjools> the forwarders file is created but we need to modify named.conf.options to have an include statement
<roaksoax> bigjools: btw... i'm gonna upload maas tomorrow my morning before feature freeze. will i be able to upload lateat trunk? or what rev?
<bigjools> the config for named is a fucking PITA
<bigjools> best to check with the guys at the time
<bigjools> we have quite a lot of stuff left to land
<roaksoax> bigjools: ok i'll try to make it happen by tomorrow (not the MIR though, that would require FFe)
<bigjools> roaksoax: ok cheers.  We definitely need FFE for it then.
<roaksoax> yup
<bigjools> sorry for leaving this so late, there was so much other stuff to do :(
<roaksoax> yeah i can imagine
<roaksoax> alright then. i'll test the maas-enlist thing tomorrow and land it if everything works as expwctex
<roaksoax> and release maas
<bigjools> sweeet
<roaksoax> alrighty then. Off to bed. Have a gpod rest of the day!
<bigjools> roaksoax: cheers, sleep well
<bigjools> jtv: there?
<jtv> bigjools: here
<bigjools> jtv: we missed our call, want one?
<jtv> politics intervened for a while
<jtv> Oh!  Call!  Forgot all about that, what with all the !@#$^ going on.  Yes I do.
<bigjools> ok
<bigjools> give me 2 mins to get a drink
<bigjools> will call you
<jtv> OK
<rvba> gmb: are you available for a tiny review? https://code.launchpad.net/~rvb/maas-test/always-update/+merge/207105
<gmb> rvba: Sure
<rvba> Thanks.
<gmb> rvba: LGTM.
<jtv> bigjools: you might like https://code.launchpad.net/~jtv/maas/dbshell/+merge/207108
<rvba> bigjools: could you please review https://code.launchpad.net/~rvb/maas-test/fix-maas-admin/+merge/207111 ?
<bigjools> yep
<rvba> Ta
<bigjools> rvba: ummm lol
<bigjools> oh dear
<rvba> :)
<rvba> bigjools: the original paste I gave you was broken so it's only fair that this comes back to me :)
<bigjools> well I missed that too
<bigjools> jtv: +                subprocess.check_call(
<bigjools> +                    ['sudo', '-u', 'postgres', 'psql', database])
<bigjools> did that actually work?
<bigjools> oh you're doing it differently to how I did it earlier, never mind
<bigjools> rvba: is it wrong of me to find it hilarious that you continually get caught out by the "additional revisions" tarmac message? :)
<rvba> bigjools: it is, indeed, wrong of you :).
<bigjools> rvba: so why is maas-test qa complaining about bin/pip?
<rvba> Well, I'd be happy to know.  Like I said, I can't reproduce it locally or on canonistack.
<bigjools> let's just fix the damn makefile
<bigjools> bin/python -m pip
<bigjools> I tried but one of the lines starting .deps/bin/pip confused me
<jtv> bigjools: do we have enough information to implement the card "Node MACs must be linked to their networks" to your satisfaction?
<bigjools> jtv: I think the card says it all
<jtv> AFAICS we only have that information for NICs that are on the MAAS-managed network.
<jtv> So... only one MAC per node linked, and only if DHCP management is enabled?
<bigjools> yeah we need to link MACAddress with network
<jtv> We can't.
<bigjools> we need to :)
<jtv> We can link MACAddress with NodeGroupInterface.
<bigjools> no
<bigjools> that's not the same thing
<jtv> That's why I said it.
<bigjools> this is manual input
<jtv> So... additional schema, additional UI.
<bigjools> not auto
<bigjools> yes :(
<jtv> And API changes.
<bigjools> yes
<bigjools> otherwise users won't know which NIC can access which network
<bigjools> we need to think carefully about the UI
<bigjools> might need some JS
<rvba> Hi rbasak, I just got a pretty confusing error from uvt-kvm.  Looks related to the data it got from simplestreams but you might know better: http://paste.ubuntu.com/6959216/
<rvba> jtv: time for a review? https://code.launchpad.net/~rvb/maas/network-mac-rel/+merge/207135
<jtv> rvba: that's a WIP
<rvba> jtv: not anymore
<jtv> Saved by the bell!
<jtv> Sorry, I made promises, remember?  :-)
<rvba> gree
<rvba> grrrr* even
<jtv> Sorry!
<jtv> If it doesn't get reviewed, I can just branch off it â no biggie.
<jtv> nn!
<rvba> nn
#maas 2014-02-20
<jtv> bigjools: looks like "make lint" is broken in a really weird way...  tries to run "tail" on lp:~maas-maintainers/maas/packaging/debian/changelog (not even head, which would seem to make more sense)
<bigjools> jtv: whut
<bigjools> jtv: oh ARGH
<bigjools> my change has a boo boo
 * bigjools fixes
<jtv> Ah, it's all "make" attempts that get this â it's just that the message is sometimes drowned out by other output.
<bigjools> jtv: yes, I was convinced by Gavin to use the lp branch but forgot it needs checking out somewhere ...
<bigjools> so I've gone back to the old way for now until I figure out a sensible approach
<bigjools> jtv: just got a random test failure
<bigjools> ERROR: maasserver.models.tests.test_node.NodeManagerTest.test_node_can_be_multiple_networks
<bigjools> ValidationError: {'vlan_tag': [u'Network with this Vlan tag already exists.']}
<jtv> lemme look
<jtv> Aigh.
<jtv> Nastiness.
<jtv> Not much we can do about that one I suspect.
<jtv> Unless...
<jtv> We could start writing "plural" factory methods.
<jtv> "Make me <n> networks."
<jtv> Which would then be responsible for preventing these clashes.
<bigjools> jtv: do you know how to conditionally set a variable in Makefile? It evaluates everything on startup, even stuff inside a target
<bigjools> I tried some shell but the value gets thrown away after...
<jtv> No, haven't had time to mess with that stuff for years...  Gavin's the one to ask.
 * jtv used to be knee-deep in GNU Make.
<bigjools> me too
<bigjools> not done one from scratch for 8 yuears
<jtv> The friend and former colleague who showed me how to set up all the really hard stuff isn't even alive any more...
<jtv> Didn't quite get to see his 20th anniversary with Debian.  :(
<jtv> I don't suppose we care if our Makefile is GNU-specific.
<bigjools> victory is mine
<jtv> No!  I saw it first!
<jtv> Er, what?
<bigjools> makefile victory
<bigjools> it's looking nice now
<bigjools> branch forthcoming
<jtv> But does it work?
<bigjools> yes!
<jtv> Review also forthcoming.
<jtv> Once you let me know the MP is ready, of course.
<bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/makefile-packaging-target/+merge/207348
<jtv> Coming right up.
<bigjools> the only thing I know will fail is if you have no-trees on by default (like me) when branching
<bigjools> but there's no option that's the opposite of --no-tree on branch :(
<bigjools> jtv: what is that migration actually changing in PG?
<bigjools> I can't see any change
<bigjools> other than the django field name
<jtv> It might change it from a fixed-length varchar to a regular varchar.
<jtv> But yes, this is more of a UI change.  Did anyone mention lately that the layers get a little muddled in Django?
<bigjools> jtv: django does not do varchar
<bigjools> everything is fixed
<jtv> Well... it creates varchar fields.
<jtv> But of fixed lenghts.
<bigjools> look at the migration, nothing changed!
<jtv> It's called "varchar" because nul-terminating strings was a novel thing at the time.
<bigjools> heh
<jtv> Space-padding used to be quite normal and socially acceptable.
<jtv> Now, I hesitate to mention it in public.
<jtv> Argh!  Yup, it's still 255 characters wide.  Damn.
<bigjools> I think the field is only used as a hint for the UI
<jtv> The difference in field width is, yes.
<jtv> I mean
<jtv> sorry
<jtv> The difference in field _type_.
<bigjools> yes
<jtv> Want me to bump up the inanely fixed maximum size?
<jtv> Oh wait, it looks like you _can_ remove that size on a TextField, and get a proper varchar!
<bigjools> !
<jtv> Unstoppable progress.  Plunging head-first into the 1990s.
<bigjools> Django - unchained
<jtv> bigjools: I updated my multiline-network-description branch with the unlimited description size.  Could you give it another go?
<bigjools> jtv: done
<jtv> Thanks.
<bigjools> jtv: make sure input is sanitised before display
<bigjools> don't want another xss
<jtv> That's what I added that test for.
<jtv> Don't know why that wasn't tested in the original Vlan class, but the <pre> doesn't really change anything there.
<bigjools> ok
<jtv> rvba: better get landing.  :)
<rvba> jtv: landing my branches now.
<jtv> \o/
<rvba> jtv: I've got another one up for review: https://code.launchpad.net/~rvb/maas/network-mac-link-net-page/+merge/207210
<jtv> On it.
<bigjools> hey rvba
<rvba> Thanks.
<rvba> \o bigjools
<rvba> jtv: rarg, you landed a migration.  It's conflicting with my branchâ¦ I'm fixing my branch nowâ¦
<jtv> Oh!  Yes...  I didn't realise we'd be clashing for a migration number.  Very sorry.
<jtv> bigjools: any chance you could look at this MP?  https://code.launchpad.net/~jtv/maas/enlist-restore-avahi-code/+merge/207362
<bigjools> jtv: sorry dinner time, later if nobody beat me to it
<bigjools> and I was OTP before
<rvba> jtv: I'll have a look in just a sec.
<rvba> Fixing the migration first.
<rvba> (Was OTP before too)
<rvba> jtv: conflict in https://code.launchpad.net/~jtv/maas/api-connect_macs/+merge/207374
<bigjools>     from maasserver import messages
<bigjools> ImportError: cannot import name messages
<bigjools> loads of that when I run tests on trusty
<jtv> Grrr
<jtv> bigjools: got the packaged apiclient installed?
<jtv> Need to remove that.
<bigjools> oh problaby.... meh
<jtv> Sometimes I think we need not just a file with requirements but one with antirequirements as well.
<jtv> "If you have any of these installed, things will break."
<bigjools> I wonder if we can fix this one day
<bigjools> it's useful to have packages installed as well
<jtv> Yes...  I wonder why the branch versions don't simply take precedence over installed packages.
<rvba> jtv: I guess a cleanup branch is in order to use the new make_networks() factory method in all the code I just landed.
<jtv> rvba: always nice!
<jtv> rvba: want me to do it?
<rvba> jtv: if you don't mind.  I'd like to work on the "Disallow single MAC on multiple non-VLAN networks" task.
<rvba> It's not trivial.  Requires the introducing of form-level validation where we don't even use forms.
<jtv> :-/
<arges> hi. is there some docs on xinstall_preseed with curtin? i'd like to be able to use the fastpath installer and then install an hwe kernel on a maas node. Thanks
<arges> http://astokes.org/customizing-fastpath-curtin-installations/ answers it
<evilnickveitch> hello. does the tftp server for images live on the cluster controller or the region controller?
<roadmr> evilnickveitch: methinks it lives on the cluster controller, but I'm just speculating
<evilnickveitch> the docs tend to suggest it does, but if i configure rgion controller to a different address, the tftp server seems to disappear too
<evilnickveitch> but thanks for your speculation roadmr  :)
<roadmr> oops :( that I have no idea, I have both on the same hardware
<ccope> does anyone know if Canonical sells support for MAAS?
<ccope> nvm found it in a pdf, the answer is yes
<bigjools> evilnickveitch: yes the images all live on the cluster
<bigjools> but the cluster needs to talk to the region to ascertain the kernel params and whatnot
#maas 2014-02-21
<evilnickveitch> bigjools, thanks
<bigjools> evilnickveitch: pleasure as always
<rvba> jtv: reviewing your branch now.
<jtv> Thanks!
<rvba> jtv: I assigned the "drop old relation" card to myself.  I've got it in progress but of course it's still blocked for now.  As I said in the email I sent you, I'll run the tests from time to time so we can see how far we are with the refactoring.
<jtv> I did the same.
<rvba> Okay :)
<Lord_Set> What upcomming changes are coming to MAAS with Ubuntu 14?
<jtv> Lord_Set: a start is in the bugs list for MAAS on Launchpad, where you can select the 14.04 milestone: https://launchpad.net/maas/+milestone/14.04
<jtv> The Fix Committed / Fix Released ones are done.
<Lord_Set> Awesome thank you
<jtv> There's also the blueprints; I'm looking up the link.
<Lord_Set> I was mainly curious about the new features if any :) But bug fixes are always welcome
<jtv> Lots of grey area between them!  But the features are in blueprints; see https://blueprints.launchpad.net/maas/
<Lord_Set> and hopefully improved Openstack deployment with Juju
<jtv> Or just the ones for 14.04: https://blueprints.launchpad.net/maas/1.5
<Lord_Set> :)
<Lord_Set> Is Juju under different development than MAAS?
<jtv> Yes, different groups.
<jtv> They hang out in #juju.  :-)
<rvba> jtv: (talking about the "update "node" filter in networks listing" work) I'm wondering if we still want to pass node system IDs to the network listing API method.  We probably want to pass MAC addresses now right?
<jtv> rvba: not entirely sure tbh...
<jtv> I wouldn't be surprised if we'd end up wanting both.
<jtv> I was thinking to wait until we hear that somebody needs it.  :)
<rvba> jtv: okay, nodes are probably more central to MAAS than MACs so I'll just adapt the existing method.
<jtv> Right.
<jtv> The main thing is that we don't leave it to block the abolition of the old linking able.
<rvba> Yep.  That's the only remaining thing AFAIK.
<jtv> It's how I found it.  :)
<jtv> factory.make_networks() still needs an option for either "only VLANs please" or "at most one non-virtual network please."
<jtv> Otherwise we're going to have trouble when we start enforcing the rules for how MACs connect to networks.
<jtv> It'll be easier though if we only enforce that at the form level...
<rvba> jtv: I'm getting this from time to time: http://paste.ubuntu.com/6969880/
<rvba> Would you mind having a look?
<jtv> That's what I'm talking about.
<jtv> The fix is landing.
<rvba> Ah, ok, cool :)
<rvba> jtv: I've got a branch up for review if you have time for it: https://code.launchpad.net/~rvb/maas/update-node-filtering/+merge/207603
<jtv> rvba: careful â the new relationship introduces an additional way for a call like this to go wrong.
<jtv> I'll look at it after the call.
<rvba> jtv: hum, I see what you mean, let me add a testâ¦
<rvba> jtv: I've improved one of the tests on https://code.launchpad.net/~rvb/maas/update-node-filtering/+merge/207603
<rvba> jtv: please have a look when you have some time.
<jtv> OK.
<jtv> Diff's still updating... weird how that's usually very fast now, and then sometimes slow like this.
<rvba> jtv: the improvement is minor, you can review what you see now.
<jtv> nm it just updated
<jtv> Done
<rvba> Thanks.
<jtv> rvba: my branch is up for review.  After that, ditching the old linking table still breaks maasserver.views.tests.test_networks.NetworkDetailViewTest.test_network_detail_displays_node_count
<jtv> It looks easy to fix, but there is a pitfall of double-counting.
#maas 2014-02-22
<designated> I have modified /etc/maas/import_pxe_files to only include precise but for some reason when I run maas-cli maas node-groups import-boot-images, it still downloads all of the images.  any idea why?
<designated> *only precise
<designated> nvm, i had the lines commented out...been a long day.
<designated> time for a little break
<roaksoax> designated: sudo maas-import-pxe-files would do that trick
#maas 2015-02-16
<atc3030> kiko, sorry just saw you ping'd me
<TheFezzer> Hi all! Does anyone know how to configure the squid3 proxy in MAAS 1.7?
#maas 2015-02-17
<dimitern> rvba, blake_r, mpontillo, roaksoax, maas+juju net call?
<kiko> dimitern, they are sprinting this week fwiw
<rvba> Hi dimitern.
<dimitern> kiko, rvba, hi
<dimitern> ok, nothing new
<dimitern> happy sprinting ;)
<travnewmatic> hello all, got an enlistment question
<travnewmatic> the first node that i'm trying to add to my maas cluster boots from pxe, ultimately ends up at an ubuntu login prompt, but my cluster controller has no knowledge of the node3
<travnewmatic> of the node*
<travnewmatic> http://pastebin.com/xQedSKqV
<travnewmatic> http://pastebin.com/gXrMwwUF
<roaksoax> travnewmatic: is the node in MAAS marked New ?
<travnewmatic> the node does not show up anywhere in my maas interface
<travnewmatic> but it did boot into an os over the network
<travnewmatic> so the dhcp stuff is working
<travnewmatic> and i can ping it
<travnewmatic> but its like the region controller or the cluster controller have no knowledge of it
<roaksoax> travnewmatic: so it needs to dhcpd from maas, then pxe, then you will see a prompt like maas-enlist
<roaksoax> travnewmatic: and the node needs to do stuff inseide of itself to register itself in maas
<travnewmatic> hmm
<travnewmatic> well iknow dhcp is working
<travnewmatic> and the pxe part is pushing an image to the server
<travnewmatic> i see a table
<travnewmatic> net device info
<travnewmatic> route info
<travnewmatic> and then it goes into some url_helper.py[WARNING] stuff
<travnewmatic> errno 113 no route to host
<travnewmatic> http://i.imgur.com/A5D5hXR.jpg
<travnewmatic> then this http://i.imgur.com/RE4cHtm.jpg
<travnewmatic> aaaaand then this http://i.imgur.com/6SqfzvD.jpg
<travnewmatic> and if i hit enter the usual ubuntu login: pops up
<roaksoax> travnewmatic: can your nodes contact 192.168.100.2 ?
<roaksoax> travnewmatic: 192.168.100.2 is the address of the MAAS region server?
<roaksoax> travnewmatic: it seems the nodes can't access it
<travnewmatic> yes!
<travnewmatic> hmm :|
<travnewmatic> alright
<travnewmatic> subnet issue?
<roaksoax> travnewmatic: that might be it. can you ensure your nodes would be able to ping the maas server?
<travnewmatic> lemme check
<roaksoax> travnewmatic: is the DHCP range configured in maas in the same network, and can actually ping?
<travnewmatic> well
<travnewmatic> as it is now
<travnewmatic> i only have one node
<travnewmatic> and that node is presenting me with a login prompt
<travnewmatic> and i'm not sure what the un/pw is
<travnewmatic> also
<travnewmatic> i first setup the region controller
<travnewmatic> then i setup the cluster controller
<roaksoax> travnewmatic: that's fin
<roaksoax> travnewmatic: let the user auto register itself in maas, and you will see it appear there
<travnewmatic> hmm
<travnewmatic> well i ran the dkpg configure cluster controller command thing
<travnewmatic> put in the api address of the region controller
<travnewmatic> and added the second maas controller to the first
<travnewmatic> so the first maas controller, the 192.168.0.2 machine, lists 2 clusters
<travnewmatic> on the region controller, i went into that added cluster controller and added a managed interface, with dhcp and dns
<travnewmatic> the cluster controllers address is 192.168.0.3
<travnewmatic> when i go to  192.168.0.3/MAAS
<travnewmatic> its like everything is fresh
<travnewmatic> i dont see that managed interface that i created
<travnewmatic> although it does exist on the  192.168.0.2 interface for the  192.168.0.3 cluster controller
<roaksoax> travnewmatic: that's because you don't need to install the Region controller on the Cluster controller
<travnewmatic> aaaaaah okay
<roaksoax> travnewmatic: when you install sudo apt-get install maas , it will install both Region (maas-reiogn-controller) and Cluster (maas-cluster-controller)
<travnewmatic> uhuh
<roaksoax> travnewmatic: if you want to add *another* cluster controller, which is not running on the same machine of the region, you only have to install maas-cluster-controller, and then dpkg-reconfigure maas-cluster-controller to point it to the *region* controller
<travnewmatic> mmm i see
<travnewmatic> when i did the cluster controller, i did it from the ubuntu server install media maas option
<roaksoax> travnewmatic: so the base installation (sudo apt-get install maas) should allow you to control your maas and configure the *default* cluster (the one runnin with the region)
<travnewmatic> mhm
<roaksoax> travnewmatic: and if you have nodes that can talk ot the maas server, you just need to allow them to PXE boot and that's it
<travnewmatic> so the cluster controllers act as intermediaries between nodes and the region controller
<roaksoax> travnewmatic: correct
<travnewmatic> hmm
<travnewmatic> https://www.dropbox.com/s/bjhn5qrs3ma02rf/Screenshot%202015-02-17%2015.59.38.png?dl=0
<travnewmatic> so if i wanted to put everything on the same subnet
<travnewmatic> i think right now i'm using 192.168.0.1 through 192.168.0.4
<travnewmatic> what is the router ip?
<roaksoax> travnewmatic: depends whether you hvae a default gw, or maas is your default gw
<travnewmatic> i've got a box doing nat
<travnewmatic> so 192.168.0.1 is what i've got everything point to for their gateway
<roaksoax> travnewmatic: say, your router is 192.168.0.1, your maas server 192.168.0.2. When you configure your dynamic range, it will use 0.4 to 0.14, and static range from 0.15 to 0.25
<roaksoax> travnewmatic: so router address is 192.168.0.1
<travnewmatic> mhm
<catbus1> looks like he has 1.5 there. not 1.7.
<catbus1> maas I mean.
<roaksoax> travnewmatic: ah, so if there's just 1 range, then you only need 1 range
<travnewmatic> i'm putting everything on 192.168.0.0
<travnewmatic> http://pastebin.com/0nRnmUpH
<travnewmatic> https://www.dropbox.com/s/duoi6f19nt8vlw5/Screenshot%202015-02-17%2016.10.59.png?dl=0
<travnewmatic> aaand now dhcp and pxe is borked :D
<travnewmatic> restarting my cluster controller
<travnewmatic> the cluster controller has the only managed interface
<travnewmatic> i forgot to change the network in the network tab in the maas interface
<travnewmatic> might that have had something to do with it?
<catbus1> dpkg-reconfigure maas-cluster-controller didn't help to get dhcp back?
<travnewmatic> yaaay pxe works again
<travnewmatic> i think
<travnewmatic> hmm
<travnewmatic> now its just sitting there
<travnewmatic> TFTP.
<travnewmatic> gateway ip is 192.168.0.1
<travnewmatic> http://imgur.com/2vQfpf7
<travnewmatic> hanging on the tftp thing
<travnewmatic> HNNNG it should be .2
<travnewmatic> hold on
<travnewmatic> should it?
<travnewmatic> my gateway to my nat box is .1
<travnewmatic> region controller is .2
<travnewmatic> cluster controller is .3
<travnewmatic> and the interface with dhcp is .4
<catbus1> You set the router IP to 192.168.0.1. It should be .1.
<travnewmatic> so thats right?
<travnewmatic> yeah its still hangin on the tftp thing
<catbus1> That's right, it's getting IP address from the dhcp server which you set to .4. But I *think* the node needs to reach cluster controller to get the image files.
<travnewmatic> but it is getting an address from dhcp
<travnewmatic> hmm
<catbus1> could you set eth1 internface as unmanaged on maas web ui, and set eth0 interface to manage dhcp and dns with the same settings, except IP would be 192.168.0.3 not 192.168.0.4.
<travnewmatic> this is odd i was getting farther with having stuff on a separate subnet
<travnewmatic> hmm alright i can try that
<travnewmatic> so i'll ditch eth1
<travnewmatic> https://www.dropbox.com/s/026yyfjix0h5zpr/Screenshot%202015-02-17%2016.32.13.png?dl=0
<travnewmatic> didnt ditch it just set it to unmanaged
<catbus1> that looks good.
<travnewmatic> and moved the config stuff to eth0
<catbus1> config stuff?
<travnewmatic> i mean
<travnewmatic> the dhcp and dns form stuff
<travnewmatic> router ip , high, low, etc
<catbus1> right.
<travnewmatic> aaaaaand we're on our way
<travnewmatic> pxe pushing stuff over as it should
<travnewmatic> maas-enlisting-node login!
<travnewmatic> wow thanks guys this is really flipping sweet
<catbus1> great. does the node show up on the nodes page on maas web ui now? as New.
<travnewmatic> mmm
<travnewmatic> does not :(
<catbus1> or Declared
<catbus1> the node should power off, after that it will show up on the web UI.
<travnewmatic> erhmahgerd thats exactly what it did
<travnewmatic> https://www.dropbox.com/s/8v58n0ppiswxhoa/Screenshot%202015-02-17%2016.37.28.png?dl=0
<travnewmatic> https://www.dropbox.com/s/q33bvk4nz7s5wgx/Screenshot%202015-02-17%2016.38.00.png?dl=0
<catbus1> great. now you can commission the node, so MAAS knows how many CPU cores and RAM it has.
<travnewmatic> i'm not sure it knows how to power it back on
<catbus1> Click Edit node on the node page.
<catbus1> MAAS should have created IPMI credentials to power control the node.
<travnewmatic> did not :(
<travnewmatic> manually powering it back on
<catbus1> could you show the screen shot of the node details page (click Edit node).
<travnewmatic> unmomento
<travnewmatic> https://www.dropbox.com/s/10b8tv3izrs9jmp/Screenshot%202015-02-17%2016.44.55.png?dl=0
<catbus1> It says the cluster controller for this node is not responding, power type validation is not available.
<travnewmatic> :(
<catbus1> do you mind doing dpkg-reconfigure maas-cluster-controller again to make sure you tell the cluster controller where region controller is?
<travnewmatic> after the restart https://www.dropbox.com/s/ids7cnfcm1jntu7/Screenshot%202015-02-17%2016.47.40.png?dl=0
<travnewmatic> done
<catbus1> If it's all working as it should, you should not need to power on/off the node manually, MAAS should take care of that for you.
<catbus1> MAAS region controller API URL should be http://192.168.0.2/MAAS for the cluster controller configuration.
<travnewmatic> yep thats exactly what i put
<catbus1> you mentioned you had two cluster controllers.
<travnewmatic> no, a region and a cluster
<catbus1> ok.
<catbus1> i don't remember exactly how maas 1.5 should show the power control info on the node page.
<travnewmatic> well
<travnewmatic> thres a dropdown in the edit page "power type"
<catbus1> MAAS should have it filled up automatically after the enlistment.
<catbus1> i don't know what log files to look at in /var/log/maas/ to find out what's going on.
<travnewmatic> ERROR 2015-02-17 16:54:46,136 maasserver Unable to get RPC connection for cluster 'maas'
<travnewmatic> might this be it?
<catbus1> https://bugs.launchpad.net/maas/+bug/1350925
<ubot5> Launchpad bug 1350925 in MAAS "Unable to get RPC connection for cluster 'maas'" [Critical,Fix released]
<travnewmatic> poop
<catbus1> could be DNS hostname resolve issue
<travnewmatic> hmmmm
<travnewmatic> or an ssh key issue
<catbus1> does putting hostname in the /etc/hosts file help?
<j^2> if anyone uses chef here, i just pushed up: https://rubygems.org/gems/knife-maas
<j^2> it would be awesome if yall could give it a shot and report any bugs to the issues page
<travnewmatic> catbus1, on the region controller?
<travnewmatic> yeah i tried it on another 1950 and it doesnt like the ipmi
<travnewmatic> i see that thread though
<travnewmatic> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1321885
<ubot5> Launchpad bug 1321885 in openipmi (Ubuntu) "IPMI detection and automatic setting fail in Ubuntu 14.04 maas" [Undecided,Confirmed]
<catbus1> travnewmatic: I am not sure actually. I have never deployed region and cluster on different nodes. Region couldn't contact cluster, and it could be name resolving issue, cluster is providing DNS service, so region should reach to cluster for DNS service. I would try this, edit /etc/resolv.conf and have cluster controller IP as the first nameserver entry, and see if it works.
<travnewmatic> well
<travnewmatic> i could try cutting out the cluster controller
<travnewmatic> does this not appear to be an issue with the ipmi in the 1950?
<travnewmatic> my error does seem to match what is described in that bug
<catbus1> it could be related to hardware. yes.
<catbus1> travnewmatic: you can find your maas version with apt-cache policy maas
<travnewmatic> 1.5
<catbus1> fix verified with 1.7
<travnewmatic> so i should upgrade
<catbus1> travnewmatic: you can get 1.7.1 from maas-maintainers/stable ppa, sudo add-apt-repository ppa:maas-maintainers/stable
<travnewmatic> gotcha
<catbus1> sudo apt update and sudo apt install maas
<catbus1> choose to use the new configuration template during the install maas process. after it's upgraded to 1.7, you need to re-import the image files and there is a new IP range (Dynamic and Static) in the network interface you will need to configure.
<travnewmatic> hmm i see
<travnewmatic> both region and cluster are upgrading
<travnewmatic>  Y or I  : install the package maintainer's version
<travnewmatic> this is what you're referring to?
<catbus1> yes.
<travnewmatic> gotcha
<travnewmatic> i really appreciate all the help this afternoon
<travnewmatic> shit you guys are awesome https://www.dropbox.com/s/0rq88uhv6872tcb/Screenshot%202015-02-17%2017.39.57.png?dl=0
<travnewmatic> i was wondering why some of the screenshots in some of the guides looks a tad different than what i was seeing on my screen
<travnewmatic> wow it seems like this update adds a lot
<travnewmatic> also it appears that my cluster controller has been disconnected from my region controller after the upgrade
<j^2> travnewmatic: yeah 1.7.1+ is the way to go
<j^2> most of the docs are 1.5
<travnewmatic> ive noticed
<travnewmatic> hopefully the documentation will catch up soon
<travnewmatic> where does juju get installed?  on the region controller?
#maas 2015-02-18
<catbus1> travnewmatic: you can install juju-core anywhere, in the ~/.juju/environments.yaml, you will tell Juju where to find MAAS and provide the MAAS API key in order to communicate with MAAS.
<travnewmatic> oh boy
<travnewmatic> well
<travnewmatic> right now my region controller can't see the cluster controller
<travnewmatic> i've rebooted both
<travnewmatic> did the dpkg-reconfigure maas-cluster-controller on the cluster controller
<travnewmatic> but they still arent talking
<travnewmatic> https://www.dropbox.com/s/qqm2jcppt13ctzx/Screenshot%202015-02-17%2018.03.16.png?dl=0
<travnewmatic> they can ping each other
<catbus1> what is tnewman3 - region controller?
<travnewmatic> thats .2
<catbus1> you have two cluster controllers there.
<travnewmatic> hmm
<catbus1> .2 should be the region controller, right?
<travnewmatic> .2 is the region controller
<travnewmatic> yes
<travnewmatic> and .3 is the cluster controller
<catbus1> tnewman4 is not connected.
<catbus1> what is tnewman4?
<travnewmatic> yeah tnewman4, 192.168.0.3, is the cluster controller
<travnewmatic> before both the region and cluster controllers would show up under the 'Clusters' tab
<travnewmatic> and they still do
<travnewmatic> but for some reason tnewman3 isnt connecting to tnewman4
<catbus1> The clusters tab should only show cluster controllers.
<travnewmatic> hmm
<travnewmatic> alright well i deleted tnewman 3
<catbus1> I would keep it actually.
<travnewmatic> poop
<travnewmatic> hmm
<catbus1> so that both cluster and region controllers are on the same node.
<travnewmatic> hmm
<travnewmatic> well
<catbus1> that's how I have been deploying them.
<catbus1> but it's up to you.
<travnewmatic> region and cluster controller are the same node?
<catbus1> They *can be* on the same node.
<travnewmatic> uhuh
<travnewmatic> well right now my problem is i have a nonfunctioning cluster ctroller on my region controller :D
<catbus1> I guess you renamed the cluster controller as region controller, but it's a cluster controller.
<travnewmatic> i see
<travnewmatic> well
<travnewmatic> how do i delete it and re-add it
<catbus1> I'd use tnewman3 as the cluster controller since it's already connected, make sure images are imported fine, configure tnewman3 to manage DHCP and DNS. Remove DHCP and DNS services from tnewman4.
<travnewmatic> alright
<travnewmatic> well
<travnewmatic> right now the tnewman4 is a stub
<travnewmatic> i can't delete it because i can't connect to it
<travnewmatic> Error: Unable to connect to cluster 'tnewman4 - cluster controller' (1b03b5d4-ff03-4178-bdeb-4340cf2238bc); no connections available.
<catbus1> ok. leave it as is then. Hopefully it won't compete to offer IP addresses.
<catbus1> or you can shut down eth1 on .3.
<travnewmatic> i just turned it off
<travnewmatic> uuung i got this all screwed up
<travnewmatic> possible to reinitialize the maas installation?
<travnewmatic> i'll just keep everything on one node
<travnewmatic> region, cluster, juju when the time comes
<travnewmatic> but right now if i could just reinstall the region controller and the cluster controller with clean everything tht'd be awesome
<catbus1> yeah, reinstall 14.04 server base and install maas from the maas-mainstainers/stable ppa should take ~10 minutes?
<travnewmatic> alrighty then
<travnewmatic> does 1.7 come automatically with 14.10?
<catbus1> there may be an easier way to do it. but I don't know any other way.
<travnewmatic> yeah
<travnewmatic> no biggie
<catbus1> no, 1.7.1 is released recently.
<travnewmatic> ah
<catbus1> you have to get it from the same ppa on 14.10, too.
<travnewmatic> gotcha
<travnewmatic> is this something that canonical is going to develop the hell out of?
<travnewmatic> not just a flash in the pan
<catbus1> I think we are pretty serious about it. :)
<travnewmatic> yeeeeah :D
<travnewmatic> again, suuuper appreciate the time today
<travnewmatic> i work for a hosting company in a data center
<travnewmatic> we have a provisioning tool we call daris
<travnewmatic> not sure if thats an industry standard or anything
<travnewmatic> but for us, right now, it only does centos 6.5 provisions
<travnewmatic> which isnt so bad, because most of our provisions are for centos 6.5
<catbus1> travnewmatic: what brings you to MAAS?
<travnewmatic> but thats not going to work indefinitely
<travnewmatic> uuuum curiousity
<travnewmatic> a potential alternative to our existing provisioning server
<catbus1> great, I though you may have seen this https://insights.ubuntu.com/2014/11/14/bare-metal-magic-at-the-open-compute-summit/
<travnewmatic> i had not, but thats really flipping cool
<travnewmatic> i think once i get this up and working, the next thing to do would be to figure out how to add non ubuntu images to the server
<travnewmatic> and other linux distros as well
<travnewmatic> well what do you suggest my next step would be
<travnewmatic> how do you use it in the real world
<catbus1> I haven't tried that myself. Would be interesting to find out the experience of deploying non-Ubuntu images.
<travnewmatic> well from what i've read supposedly it is possible
<catbus1> I don't work in a data center, I do not have experience as data center admin.
<travnewmatic> mhm
<travnewmatic> https://insights.ubuntu.com/2014/11/20/maas-1-7-one-maas-multiple-operating-systems/
<travnewmatic> well what is your role with maas
<travnewmatic> are you a developer?
<catbus1> I work with hardware vendors and MAAS team to help make sure MAAS can provision hardware.
<travnewmatic> that sounds fancy
<catbus1> IPMI isn't the only power control type we support.
<travnewmatic> yeah i noticed that in the old menu
<travnewmatic> there are quite a few
<travnewmatic> reinstalled, updated to 1.7, created the superuser, rebooting
<travnewmatic> dhcp and dns config stuff
<travnewmatic> now lets get this image importation party started!
<travnewmatic> Feb 17 19:50:21 tnewman3 maas.api: [ERROR] timely-bell.local: Timed out wait
<travnewmatic> ing for power response in Node.power_state
<travnewmatic> maybe we've got some funky stuff in our ipmi's
<travnewmatic> catbus1-afk, yeah not sure what the deal is but maas still doesnt have control over startup and shutdown of my 1950
<travnewmatic> catbus1-afk, reset the DRAC to see if that will have any effect
<travnewmatic> no dice :(
<travnewmatic> Feb 17 20:33:27 tnewman3 maas.api: [ERROR] ripe-believe.local: Timed out wai
<travnewmatic> ting for power response in Node.power_state
<travnewmatic> alright i'm out for the night, thanks yall so much for the help, i'll come back to this tomorrow, yall have a great rest of the day!
<kiko> catbus1-afk, why was he using 1.5?
<catbus1> kiko: he used ubuntu server boot media to install maas.
<kiko> catbus1, ugh, we need to fix that too
<dimitern> hey guys
<kiko> hey dimitern
<dimitern> is it feasible to even try to run a ppc64el kvm in maas?
<kiko> dimitern, I think it has actually been done before
<dimitern> kiko, I mean I can see and download the ppc64el images from the maas ui, but how to setup a ppc kvm for maas to commission?
<kiko> dimitern, you want to create a ppc kvm instance on a ppc machine or on an x86 machine?
<catbus1> travnewmatic: Hi, I'd check if IPMI is enabled on your dell machine with: ipmipower -h <bmc ip address> -u <bmc username> -p <bmc password> --stat. If it's responding, I suggest you add a comment to bug 1321885 to report regression.
<ubot5> bug 1321885 in openipmi (Ubuntu) "IPMI detection and automatic setting fail in Ubuntu 14.04 maas" [Undecided,Confirmed] https://launchpad.net/bugs/1321885
<dimitern> kiko, the latter
<kiko> dimitern, does that work standalone today or is that your question?
<dimitern> kiko, on my amd64 trusty laptop
<kiko> that would be somewhat unrelated to maas itself :)
<dimitern> kiko, that's my question :) should I even try
<kiko> ah
<dimitern> kiko, fair enough it's not quite maas related, but I thought maybe I can configure my local kvm-based maas somehow to make this work
<kiko> you can if the qemu/kvm instance runs at all
<travnewmatic> catbus1, okie dokie
<dimitern> kiko, ok, that's at least something - I'll keep digging then
<dimitern> cheers!
<kiko> dimitern, I was asking slangasek
<kiko> but no answer yet
<kiko> <slangasek> kiko: I believe that ppc64el qemu system emulation works cross-platform; I wouldn't call that "kvm" though since it's of course not accelerated
<kiko> dimitern, ^^
<dimitern> kiko, thanks; I've tried creating a ppc64 VM using qemu as hypervisor and faced various issues (video driver needed to change to "vga" from "cirrus", few other things as well)
<dimitern> kiko, ultimately I got an error like "unsupported configuration: guest and host CPU are not compatible: host CPU vendor does not match required CPU vendor IBM"
<dimitern> that was after setting the cpu type to POWER8_1.0 or something
<kiko> dimitern, hmm, dunno if that's a rtfm or that you're using an old version of what
<dimitern> kiko, I'll look more into it, anyway - thanks for your help :)
<travnewmatic> catbus1, i'll take a look at it in a sec, but does the ipmi port respond to pings when the server is off?
<catbus1> travnewmatic: I am not sure. Sure it should respond to ipmi requests.
<catbus1> whether it responds to pings depends on bmc firmware.
<travnewmatic> gotcha
<CompanionCube> hi
<CompanionCube> I'm trying MAAS out with VMWare Player and while a node acquires a DHCP IP, it fails to connect to a TFTP server so it does not boot
<travnewmatic> so maybe it works
<travnewmatic> changed a setting in the DRAC config
<travnewmatic> but when i hit commission
<travnewmatic> the machine starts back up
<travnewmatic> but then just bootloops
<travnewmatic> gets halfway through the bios and then shuts down and restarts
<travnewmatic> brb lunch
<kiko> travnewmatic, that's interesting
<travnewmatic> well it did ultimately stop the bootloop
<travnewmatic> when i got back it was hanging on what nic port it should pxe boot from
#maas 2015-02-19
<catbus1> travnewmatic: so it didn't get an IP address from the MAAS?
<travnewmatic> catbus1, it did get an ip address from maas
<catbus1> but it didn't get pxe files from MAAS?
<travnewmatic> its like the maas server gave up on it after a certain period of time
<travnewmatic> timed out
<travnewmatic> ERROR	Wed, 18 Feb. 2015 16:55:46	Failed to power on node â Timeout after 7 tries
<catbus1> it failed to power on the node
<catbus1> back to power control IPMI again
<catbus1> does the node respond to the manual ipmipower command?
<travnewmatic> umm that i have not tried
<travnewmatic> the node powers back on
<travnewmatic> but like i said it does this bootloop thing
<travnewmatic> it never makes it out of the bios
<travnewmatic> and then after a while it does
<catbus1> that sounds like a firmware issue
<travnewmatic> yeah
<travnewmatic> we dont make much of use of the dracs on those models
<travnewmatic> so keeping them up to date isnt a priority
<travnewmatic> is it an outdated thing you suspect or a misconfiguration, or both
<catbus1> outdated I think, I would update the firmware. Most of the time it fixes all the odd issues. Do you have any other server than 1950?
<travnewmatic> many many other types
<travnewmatic> but it'd require some rearranging
<travnewmatic> all dell
<travnewmatic> i was thinking to try another model
<travnewmatic> but we have a ton of these older 1950's just sitting around
<travnewmatic> so it'd be pretty cool if we could get it to work on those
<travnewmatic> not to mention we have ram out the ass for those
<catbus1> In the first phase, the discovery/enlistment phase, MAAS would set a new IPMI username/password so it can power control the node from that point on. All you need to do is commission it and it will be ready to be deployed. You don't have to manually power on/off or change any BIOS settings.
<travnewmatic> right
<travnewmatic> then that will be my task for tomorrow
<travnewmatic> figuring out how to update the firmware in the 1950's
<catbus1> sounds fun
<catbus1> don't brick any
<travnewmatic> :D
<travnewmatic> is there a way to check the version?
<travnewmatic> i think i found it
<travnewmatic> actually nope i didnt
<travnewmatic> so i walked out there and checked
<travnewmatic> "Remote Access Configuration Utility Copyright 2006 Dell Inc. All Rights Reserved 1.21"
<travnewmatic> Baseboard management controller revision 1.77
<travnewmatic> Primary backplane firmware revision 1.05
<catbus1> I am not familiar with Dell servers.
<travnewmatic> poop
<travnewmatic> theres also this http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=CH9TW
<travnewmatic> actually this seems to be the most relevant http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=D8GP9
<travnewmatic> so i'm either going to need to install windows on it
<travnewmatic> or hope that red-hat version also works with centos and install that
<travnewmatic> again thanks for the help, i'll see what i can figure out tomorrow
<travnewmatic> yall have a good rest of the day
<nashville> can anyone give me a hand i am implementing a maas server and it all works it is just SUPER slow on loading boot-kernel any ideas anyone?
<kiko> nashville, yes, sure
<nashville> kiko hello old friend
<kiko> nashville, very slow tftp suggests a networking problem
<nashville> hmmm
<kiko> things to look for
<kiko> ifconfig drops errors
<kiko> switch configuration throttling udp
<kiko> the latter is VERY common if you are using a "good switch"
<kiko> everything that could mess up IP traffic could apply here
<kiko> MTU issues
<kiko> etc
<nashville> i have actually gotten it to register a node but cant get it to commission and it took forever to register
<kiko> tftp is particularly sensitive
<kiko> because it's a udp-only protocol
<kiko> tcpdump on the server side can give you some hints
<nashville> ok thats what i have been thinking it is too
<nashville> time to look at the switches
<kiko> if you can replace the switches and cables one by one
<nashville> mtu should be like 1500 im guessing
<kiko> and you'll find it
<kiko> normally on a lan it's 1500
<kiko> but some people have weirder setups
<nashville> its running on a hyper-v virtual machine
<kiko> oh!
<nashville> thats where my server is
<nashville> i was kinda wondering if i have something about the vm wrong
<kiko> http://www.altaro.com/hyper-v/troubleshooting-the-hyper-v-virtual-switch-part-1/
<kiko> https://mssecbyben.wordpress.com/2014/11/02/losing-udp-traffic-in-a-hyper-v-environment-with-nvgre-and-cant-explain-why/
<kiko> nashville, j^2 and I spent a day looking at related problems and ended up replacing the NIC on the maas host which was dropping packets like crazy
<nashville> like inside the server you replaced the actual hardware?
<kiko> yes
<kiko> ifconfig showed the way
<j^2> nashville: yep, we went through the whole 7 layers and it turns out it was a layer 1 problem
<nashville> ugh thats nasty i really hope thats not it
<nashville> ok for some reason when i do ifconfig as the maas user it gives me problems
<nashville> that doesnt matter it happens on my working server
<kiko> nashville, sudo ifconfig -a
<kiko> nashville, as your user may lack the right caps
<nashville> after some reading thanks kiko i think my problem is vmq gonna disable that and retest and ill let you guys know thanks kiko
<kiko> nashville, let me know if it works and I'll release note
<nashville> @kiko well that was it buddy disabled vmq in hyper-v (2012r2) and its BLAZING now
<nashville> you are the man/woman kiko thanks a ton
<kiko> nashville, it's those pesky windows people
<kiko> heh
<kiko> enjoy
<kiko> nashville, how many nodes?
<kiko> and why did you chose to run maas inside hyper-v?
<kiko> are you a windows shop?
<nashville> right now just ten but it is easily going to climb to the thousands
<nashville> no actually i dont know why they did it that way
<kiko> hmm
<kiko> it does make testing easier
<nashville> basically i think they bought the server and didnt know what to do with it so they put 2012 on there and hyper-v
<kiko> but not running on the bare metal can make the networking a bit more complex
<kiko> I see
<kiko> who is they, procurement?
<nashville> im just a contractor here so i dont know the whole story
<nashville> more like "engineering"
<nashville> heh
<kiko> heh
<nashville> this makes twice you have saved me during this project kiko let me know where you would like your beer sent
<kiko> nashville, I want a blog post actually :)
<nashville> i could do that... but kiko, honestly i basically followed exactly what you sent me
<nashville> specifically:
<kiko> I know! but a blog post that says "maas works great" and "here were the gotchas" is great publicity
<nashville> http://www.altaro.com/hyper-v/troubleshooting-the-hyper-v-virtual-switch-part-1/
<nashville> part two
<nashville> oh
<nashville> yeah i can def do that!!!
<kiko> i.e. something like I did for dhcp/dns here: http://kiko.ghost.io/things-i-wish-id-known-about-nsupdate-and-dynamic-dns-updates/
<nashville> when i get off tonight ill write one up and put it in the chanel so you can see it
<kiko> cool thanks!
<jamespage> roaksoax, https://bugs.launchpad.net/juju-core/+bug/1423626 fyi
<ubot5> Launchpad bug 1423626 in maas (Ubuntu) "Inconsistent device naming depending on install method" [Undecided,New]
<jamespage> roaksoax, I spent most of today helping a guy in #juju who could not get his LXC containers to get network addresses :(
<kiko> jamespage, hmm!
<jamespage> kiko, my exact comment was "!!!eeek"
<kiko> jamespage, I bet roaksoax would say "d-i is going away"
<kiko> jamespage, but the actual bug if I understand your comment is with d-i, which by using biosdevname to install causes the interface to be named "incorrectly" based on the commissioning data
<kiko> I guess the easiest solution would for d-i not to install biosdevname
<kiko> well, but is that easy?
<jamespage> incorrect/inconsistent
<jamespage> kiko, I'm not convinced that MAAS is doing anything wrong - maybe Juju should be using MAC address and not name to identity the primary network interface ?
<kiko> jamespage, perhaps, though I'm not sure maas encodes the interface name in its own logic in places
<kiko> or not sure maas doesn't encode
<kiko> at any rate, perhaps asking if juju /could/ do that to begin with might be a good starting point
<kiko> as it's the place where it could be made more robust
<kiko> i.e. the theme of accepting inputs liberally
<dimitern> there's no way to get the NIC name by MAC address at the time juju is generating cloud-init userdata for the node AFAIK
<jamespage> dimitern, kiko: in the new world:
<jamespage> http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
<kiko> dimitern, isn't the agent running and able to issue an ifconfig -a?
<jamespage> not sure whether we'll have that on by default for vivid - I'll check
<dimitern> kiko, the agent is not yet running as is the machine - this happens at allocate/deploy time
<dimitern> kiko, the agent however might do that once the machine boots
<dimitern> kiko, but that's a bit nasty - there should be a maas api for it :)
<kiko> dimitern, the problem is that the interface name might have changed
<kiko> dimitern, so while we could return to you what maas thinks the interface name on the node is
<kiko> that might have changed from commissioning to install
<kiko> as in jamespage's case
<dimitern> kiko, that's a fair point
<jamespage> kiko, dimitern: no plans to enable that specific feature for vivid/systemd
<kiko> dimitern, well, whatever code /is/ running on the machine could figure out what the interface name is
<kiko> dimitern, what is running on the machine? an ssh session?
<dimitern> kiko, juju polls the machine addresses as they become known via the cloud api and then tries to connect via ssh to all of them
<dimitern> kiko, in order to do the initial bootstrap (e.g.install mongod etc.) and then starts jujud
<jamespage> kiko, dimitern: ouch - I think I just re-opened old wounds in #ubuntu-devel
<jamespage> apparently this was enabled by default for server d-i installs under some protest from the foundations team
<jamespage> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1347859
<ubot5> Launchpad bug 1347859 in ubuntu-meta (Ubuntu) "Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems" [Undecided,New]
<dimitern> "predictable" seems like the wrong term here :)
<roaksoax> jamespage: yes, it might indeed be a juju issue
<jamespage> dimitern, 'accurate'
<jamespage> the card in slot 1 port 1 will always be addressed the same
<jamespage> irrespective of what actually plugged into it
<kiko> jamespage, except most motherboards have on-board nics that are routed who knows how ;)
<dimitern> jamespage, btw - I've just deployed a amd64 trusty node using d-i in my maas, and unlike before I can see "apt-cache policy biosdevname" is installed, but the NICs are still called ethX
<kiko> dimitern, right, so in that ssh session could we not inter the interface name based on the MAC?
<dimitern> kiko, it will be rather late then - we could do it when bootcmds are run to dump some data somewhere (maybe even the correct /etc/network/interfaces using the correct names)
<dimitern> kiko, I've commented on about this suggestion on the bug, be we need to investigate
<kiko> dimitern, uhh.. right. I am now beyond my understanding of the process :)
<kiko> thanks :)
<dimitern> kiko, np :) thanks for the discussion - it was very useful
<kiko> thanks to you
<travnewmatic> morning maas crew
<kiko> morning travnewmatic
<travnewmatic> got a bit of actual work today
<travnewmatic> then will attempt to update the ipmi firmware stuff
<travnewmatic> i'll have some help, my coworker is onboard the maas bandwagon, so i'm optimistic
<kiko> travnewmatic, at least somebody's trying to help :) where did you leave off?
<kiko> to isolate the issue, are you already able to control a machine via IPMI manually?
<travnewmatic> well maas does have some control over the hardware through ipmi
<travnewmatic> it can turn the machine on
<travnewmatic> and can turn the machine off
<travnewmatic> but theres some miscommunication going on
<travnewmatic> i mentioned the bootloops
<kiko> what is the latest symptom?
<travnewmatic> the machine will be off after having checked in with maas
<kiko> travnewmatic, you're on 1.7.1, right?
<travnewmatic> uuuuuh
<travnewmatic> how to check?
<travnewmatic> i know i'm at least 1.7
<kiko> dpkg -l | grep maas
<kiko> but you should be if you used the PPA
<travnewmatic> 1.7.1
<kiko> great!
<travnewmatic> woohoo! :D
<kiko> tell me about these fruit loops
<travnewmatic> lol
<travnewmatic> so the machine will be off after having initially checked in with the maas server
<travnewmatic> in the maas interface i'll hit commission
<kiko> by checked in do you mean what we call enlist?
<kiko> and you've accepted it into your pool?
<travnewmatic> yes, the stage before commission
<travnewmatic> so i'll click commission
<travnewmatic> the machine will turn back on
<travnewmatic> go halfway through the bios, then turn off, and then turn back on again
<kiko> so far so good
<travnewmatic> and it'll do that a few times
<kiko> through the bios? i.e. not even attempt to pxe boot?
<travnewmatic> doesnt make it that far
<kiko> okay
<kiko> this could be an issue with the fact we're telling it to network boot
<kiko> do the NICs have netboot functionality available/enabled
<travnewmatic> mmmm i would assume so, as it has been able to pxe boot before?
<travnewmatic> are those different things?
<kiko> it has?
<kiko> I see, enlist was able to pxe boot of course
<kiko> okay
<kiko> so if you power the machine on manually it does pxe boot
<kiko> but if maas tells it to power on it gets stuck mid-boot
<kiko> travnewmatic, would it be hard to video and dropbox the symptom?
<kiko> or illegal
<travnewmatic> lol i dont think it'd be illegal
<travnewmatic> i'd be happy to do that
<kiko> that makes it less fun but more effective I guess
<travnewmatic> though i wonder if it would be better for us to invest more time into updating the firmware to be current
<kiko> right, let's do that first
<travnewmatic> mhm
<kiko> and then if you are still stuck we should get a video and a model number so I can check with the certification guys
<travnewmatic> for sure
<travnewmatic> this is actually kind of cool
<travnewmatic> to think that i could contribute to the development of a peice of software used by people all over the planet
<kiko> that's rather the essence of free software
<travnewmatic> yeah!
<kiko> it's why practically all of us got into it, really
<travnewmatic> mhm
<travnewmatic> my buddy here at work contributes as well
<travnewmatic> as we work at a data center
<travnewmatic> we've got hardware and bandwidth out the wazoo
<travnewmatic> so he set up a mirror
<travnewmatic> centos in this case
<kiko> did you know maas can now provision centos?
<kiko> j^2 is working on a knife cookbook that gets it all up and running
<kiko> it's slightly unfortunate that maas is the gutter where all your hardware and networking problems run to
<kiko> so while maas itself is probably working, your hardware seems to have a mind of its own :)
<travnewmatic> yeah, i'm not holding maas accountable for our old janky out of date servers
<kiko> YET
<travnewmatic> hahah
<kiko> but soon :)
<travnewmatic> right :D
<travnewmatic> but the centos thing is kind of a requirement for us
<travnewmatic> most of the servers we provision are either centos or windows
<travnewmatic> well i guess we're lucky in that ubuntu seems to have a good partnership with dell
<kiko> with all the major vendors in reality
<kiko> but indeed, we should be able to get any issues resolved if the hardware is relatively well supported
<travnewmatic> so the adventure begins
<travnewmatic> kiko, do you have any experience with what we're about to attempt :D
<travnewmatic> kiko, http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=XCVN0&fileId=3078071536&osCode=LNUX&productCode=poweredge-1950&languageCode=EN&categoryId=ES
<travnewmatic> its doing its thing!
<travnewmatic> keep your fingers crossed
<travnewmatic> http://imgur.com/5wgYMVK
<travnewmatic> its doing the boot looping before it gets out of the bios
<travnewmatic> but the firmware is upgraded
<travnewmatic> still loopin
<kiko> hmm
<travnewmatic> but i'm watching the log and no maas error
<travnewmatic> theres the error
<travnewmatic> Feb 19 14:35:31 tnewman3 maas.power: [INFO] plain-desire.local: Power state
<travnewmatic> has changed from unknown to on.
<travnewmatic> Feb 19 14:39:55 tnewman3 maas.power: [ERROR] Error changing power state (on)
<travnewmatic>  of node: plain-desire.local (node-a20f1e7a-b876-11e4-8a8d-0015c5ef85ed)
<travnewmatic> Feb 19 14:39:55 tnewman3 maas.node: [INFO] plain-desire.local: Stopping moni
<travnewmatic> tor: node-a20f1e7a-b876-11e4-8a8d-0015c5ef85ed
<travnewmatic> Feb 19 14:39:55 tnewman3 maas.node: [ERROR] plain-desire.local: Marking node
<travnewmatic>  failed: Timeout after 7 tries
<travnewmatic> gonna try an R210
<kiko> travnewmatic, could you get an actual video of a boot-up (i.e. from the time maas triggers the commission power-on) and /msg that to me?
<kiko> I need to split tonight but I'll look later
<kiko> thanks
<travnewmatic> shore
<travnewmatic> you have a good night!
<travnewmatic> will post results!
<travnewmatic> i think my troubles may have been related to spanning tree portfast not being enabled
<travnewmatic> everything worked good on the R210
<travnewmatic> now trying it again on the 1950 with the updated firmware and spanning tree portfast enabled on the port
<travnewmatic> kiko, we're golden
<travnewmatic> it appears spanning-tree portfast was the culprit
<travnewmatic> and it also works on servers that do not have upgraded firmware
<catbus1> good news
<catbus1> travnewmatic: so you have 1950 commissioned successfully now?
<travnewmatic> indeed!
<travnewmatic> so, to do, centos, static ip's, subnets
#maas 2015-02-20
<travnewmatic> well i'm super flipping happy that i've managed to get maas setup
<travnewmatic> i got juju on one of the deployed nodes
<travnewmatic> with two machines part of that juju environment
<travnewmatic> life is good
<travnewmatic> HOWEVER..  how to centos?  can someone point me in a direction?
<catbus1> according to kiko, j^2 might know how.
<j^2> :)
<travnewmatic> :D
<j^2> ah yeah
<travnewmatic> sorry i forgot how to read :D
<travnewmatic> well j^2 can you point me in a direction?
<j^2> the tl;dr of getting Centos working: https://github.com/jjasghar/maas/blob/centos/recipes/centos.rb
<travnewmatic> ooooo
<travnewmatic> hmm
<travnewmatic> would this same thing work for centos 6.5?
<j^2> i think so but iâm not 100% sure
<j^2> my requirements where just centos7 and 1404
<travnewmatic> mhm
<travnewmatic> j^2, apparently i dont know how to execute ruby scripts
<travnewmatic> root@tnewman3:~# ruby centos.rb
<travnewmatic> centos.rb:1:in `<main>': undefined method `include_recipe' for main:Object (NoMethodError)
<j^2> oh sorry
<j^2> yeah itâs a chef recipe
<j^2> youâll have to covert it to what you need done
<j^2> the first one is check out the bazaar repo
<travnewmatic> mhm
<j^2> then the execute blocks (command) are the bash commands you need to do
<travnewmatic> so i need to install chef
<j^2> technically no, that recipe is pretty straight forward, you should be able to pull out the code that you need to repo
<travnewmatic> hmm
<travnewmatic> still not sure how to use this thing :(
<j^2> ah ok
<j^2> yeah thatâs the best i got :(
<travnewmatic> well poop
<travnewmatic> perhaps if i could find out how the ubutu image was created and deployed
<travnewmatic> so for those interested
<travnewmatic> https://code.launchpad.net/~maas-maintainers/maas/maas-image-builder
<travnewmatic> currently using this to attempt to build a centos 6 image (slightly modified to use our own mirrors)
<travnewmatic> this thing here:
<travnewmatic> sudo ./bin/build centos amd64 --centos-edition 7
<travnewmatic> for our purposes
<travnewmatic> we changed the 7 to 6
<travnewmatic> and as i mentioned before, modified the urls to our own centos mirror to speed things up a bt
<travnewmatic> bit
<travnewmatic> it seems as though it fetches the installer iso, installs it to a qemu virtual machine, takes a snapshot, and thats what gets sent to the node
<travnewmatic> right now its in the process of getting installed to the qemu vm on the maas controller
<travnewmatic> so i wonder
<travnewmatic> do yall know the guy that wrote this?
<travnewmatic> Author: Blake Rouse <blake.rouse@canonical.com>
<rbasak> blake_r: blake_r: ^^
<travnewmatic> rbasak, thats awesome!  thanks!
<mn_> Hi, i've got a problem with sticky ip addresses. even i assigned them successfully, during dhcp they are not assigned to the node - instead one from the dynamic pool is picked (using maas 1.7.1)
<mn_> any ideas what the issue could be?
<kiko> travnewmatic_, woot!
<kiko> travnewmatic_, but I thought you were not even managing to netboot -- did you get past that point or was a PXE request actually happening?
<kiko> oh I had an answer for mn_
* kiko changed the topic of #maas to:  MAAS: Ubuntu's bare-metal provisioning tool | Ask, and your question will be answered -- but be patient, it may take a few hours :)  1.7.1 released: https://bugs.launchpad.net/maas/+milestone/1.7.1 |  Docs: http://maas.ubuntu.com/docs1.7/ | Mailing list https://launchpad.net/~maas-devel
<kiko> travnewmatic_, what's the size of the resulting image?
<travnewmatic_> good news everyone!  it appears as though the image creation succeeded!  when i arrived at work this morning i was greety with this: https://www.dropbox.com/s/rbjlf7pafjk6g6t/Screenshot%202015-02-20%2010.09.25.png?dl=0
<travnewmatic_> hmm
<travnewmatic_> kiko, -rw-r--r-- 1 root root 264M Feb 19 22:02 centos6-amd64-root-tgz
<kiko> travnewmatic_, that's what I get as well
<kiko> cool thanks
<kiko> j^2, see ^^
<kiko> -rw-r--r-- 1 root root 264M Feb 19 15:26 centos6-amd64-root-tgz
<travnewmatic_> https://www.dropbox.com/s/ogv1mx9psq6tcvf/Screenshot%202015-02-20%2010.23.54.png?dl=0
<kiko> -rw-r--r-- 1 root root 264M Feb 19 13:41 centos6-amd64-root-tgz
<kiko> travnewmatic_, is your mirror public?
<travnewmatic_> our centos mirror is public yes
<kiko> I'm asking because j^2 was having issues using the default centos mirrors and perhaps switching to yours would work better
<travnewmatic_> yeah lemme find the url
<kiko> travnewmatic_, either that or a bzr diff that he can just apply as a patch?
<travnewmatic_> http://dist1.800hosting.com/centos/6/os/x86_64
<j^2> Ah that's cent6
<travnewmatic_> but we've got 7 on there as well
<travnewmatic_> browse away!
<j^2> kiko: how do I override the URL?
<kiko> travnewmatic_ has a patch :)
<j^2> Oh ok, link? And I'm not too versed in bzr, so some advice there too would be nice ;)
<travnewmatic_> i just cut and paste
<travnewmatic_> :D
<travnewmatic_> i modified the the urls in ~/maas-image-builder/builder/osystems/centos.py
<travnewmatic_> easy peasy
<travnewmatic_> you know what would be super mega flipping awesome
<travnewmatic_> is if the maas image builder was build into maas proper
<j^2> travnewmatic_: thanks for the pointer
<travnewmatic_> welcome!
<travnewmatic_> though my friend suggested that things like this are supposed to use the round robin mirror
<travnewmatic_> so the load is distributed
<travnewmatic_> but of course we dont mind we're happy to help!
<travnewmatic_>  https://www.dropbox.com/s/ql9bkd9zqyg0bq1/Screenshot%202015-02-20%2010.59.58.png?dl=0
<travnewmatic_> the shit worked
<travnewmatic_> absolutely amazing
<kiko> course it did!
<travnewmatic_> that image builder thing needs to get built into the maas front end
<travnewmatic_> for realsies
<kiko> we know
<travnewmatic_> sorry :D
<travnewmatic_> still
<travnewmatic_> this is all very very very impressive
<travnewmatic_> anything i can do to help?
<kiko> yes, blog about it :)
<travnewmatic_> i plan to ;)
<roadmr> travnewmatic_: /me should merge curtinator into maas-image-builder https://launchpad.net/curtinator
<roadmr> er... me :)
<travnewmatic_> :D
<travnewmatic_> i've seen curtains around
<travnewmatic_> but i'm not sure what that does in the grand scheme of things
<roadmr> travnewmatic_: it builds maas-installable images from stock Ubuntu isos, useful if you want to deploy ubuntu desktop using maas
<travnewmatic_> vs the maas image builder method with installs to a VM and takes a snapshot
<roadmr> travnewmatic_: that's pretty much what curtinator does, only the hooks it has are customized for ubuntu rather than rhel or centos
<travnewmatic_> hmm
<travnewmatic_> is theres a time difference?
<travnewmatic_> the maas-image-builder took a very very long time (though i can't argue with the results ;))
<roadmr> travnewmatic_: as in, how long it takes? curtinator takes about 10 minutes on an SSD system, I'd imagine about 30 on a rotary hard disk
<travnewmatic_> i think my centos bake took a few hours to complete
<travnewmatic_> granted, this isnt super bleeding edge hardware
<roadmr> travnewmatic_: if yours is much slower (i.e. takes over 1 hour), maybe you're not using hardware virtualization...
<travnewmatic_> mmmmmmmm
<travnewmatic_> tahts a good point
<travnewmatic_> the servers i'm using arent super recent
<travnewmatic_> dell 1950's
<roadmr> travnewmatic_: they should support hardware virtualization, nearly every server from the past 6-8 years should support it
<travnewmatic_> hmm then thats something i can look into
<kiko> roadmr, yeah, we should totally merge
<travnewmatic_> http://www.travnewmatic.com/2015/02/ubuntu-maas-maas-image-builder-centos-6.html
<travnewmatic_> rip it to shreds!
<catbus1> travnewmatic_: \o/
<kiko> travnewmatic_ rocks the boat
<kiko> Linux clippings, dance music, and more
<kiko> literally
<j^2> travnewmatic_: good writeup :)
<travnewmatic_> weeeew
<travnewmatic_> feedback feedback what can i add or change or what do yall recommend?
<j^2> travnewmatic_: that link to the script is to my pr isnt it?
<j^2> yeah thatâs to abranch thatâll be merged into master soonish
<kiko> j^2, when you can actually get the build to work i guess :)
<travnewmatic_> j^2, what do you mean?
<j^2> you linked a WIP branch
<j^2> kiko: sad but true yeah
<kiko> j^2, were you able to reproduce your problem?
<j^2> yep
<kiko> oh, really!
<kiko> and you don't have a transp proxy in front of you or something odd like that?
<travnewmatic_> j^2, https://code.launchpad.net/~maas-maintainers/maas/maas-image-builder <-this
<j^2> kiko: nope, itâs a direct connection
<j^2> travnewmatic_: https://github.com/jjasghar/maas/blob/centos/recipes/centos.rb
<travnewmatic_> oh thats you!
<travnewmatic_> :D
<travnewmatic_> didnt make that connection
<j^2> yep
<kiko> j^2, so two machines on your network present the same issue
<kiko> mmmmm!
<kiko> and always on different packages?
<kiko> I assume you are able to install centos standalone (i.e. not in a VM) normally..
<j^2> yep
<j^2> and yeah itâs been different pkgs
#maas 2015-02-21
<mmance> at what point does the node register with DNS?
<travnewmatic> my friend just googled "ubuntu maas centos" and i'm on the first page
<toyo|work> anyone know if juju destroy-machine is supposed to power off the server?
<travnewmatic> i thought it just removed it from the session
<toyo|work> ah
<toyo|work> so it will keep recycling them without blowing them away?
<travnewmatic> i think so
<travnewmatic> i can try!
<toyo|work> I just tried, the machines are still running
<toyo|work> I just realized I am running 6 VMs on my computer
<toyo|work> need more ram for this
<toyo|work> XD
<toyo|work> lol just spooled up a new node for nyan cat
<toyo|work> :D
<travnewmatic> blake_r, for the maas-image-builder, centos, where are the anaconda files used to automate the kvm install?
<travnewmatic> blake_r, i'm having some issues with maas-image-builder for centos 7
<travnewmatic> the process completes but the image isn't formed properly
<travnewmatic> trying again with http://mirror.centos.org/centos/
<travnewmatic> not really sure where the issue is occuring
<travnewmatic> let you know what i find
#maas 2015-02-22
<travnewmatic> also, You have not specified a swap partition.  << how to create centos images which do have swap?
<roaksoax> travnewmatic: seems to be an issue with centos, rather than our script
<roaksoax> travnewmatic: also, we do not support swap for other than ubuntu
<travnewmatic> hmm interesting
<roaksoax> travnewmatic: centos as in centos mirrors
<m_n> hi, i'm using maas 1.7.1 on trusty: but tftp for enlisting of nodes fails
<m_n> i guess it's less a connection issue as pserv.log on the cluster controller shows: [TFTP (UDP)] Datagram received from ('IP address') ...
<m_n> but fails with: [HTTPPageGetter,client] Unhandled error in Deferred:
<m_n> Failure: twisted.web.error.Error: 404 Not Found
#maas 2016-02-22
<Bofu2U> smoser: that dns v4 first trick fixed it
<Bofu2U> thank you :)
<smoser> Bofu2U, its fixed without that workaround now.
<Bofu2U> ah cool
<smoser> you can read the analysis in https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/1547640
<Bofu2U> perfect, much appreciated
<smoser> it seems taht squid just kind of goes buggy if a host has > 9 ipv6 addresses, then it never considers ivp4 ones.
<smoser> (which it woudl have correctly chosen realizing that it could not connect to any of the ipv6 addresses)
<roaksoax> durschatz: /win 15
<roaksoax> durschatz: let's do through here :)
<roaksoax> durschatz: do you have any console logs of whent he machine is trying to pxe boot and at the same time logs from /var/log/maas/regiond.log,clusterd.log ?
<durschatz> yes I do
<durschatz> what is best way to send them to you?
<roaksoax> durschatz: pastebin
<durschatz> will do
<durschatz> var_log_maas_clusterd.logvar_log_maas_regiond.logvar_log_maas_maas.log
<durschatz> var_log_maas_clusterd.log @ http://pastebin.com/UEiPubyi
<durschatz> cengnlynxpod1:var_log_maas_regiond.log @ http://pastebin.com/5zUMrUWx
<durschatz> I had to remove the top and bottom of region.log to fit it into 512k limit
<durschatz> cengnlynxpod1:var_log_maas_maas.log @ http://pastebin.com/tyYrbgDc
<roaksoax> durschatz: what about clusterd.log and a console output ?
<durschatz> var_log_maas_clusterd.log @ http://pastebin.com/UEiPubyi
<roaksoax> durschatz: the problem may be this: provisioningserver.drivers.power.PowerError: Failed to power node-87bce854-d7e7-11e5-b6c6-5254009f68e6. BMC never transitioned from  to on.
<durschatz> OK. What could have caused this to start happening after three weeks of no issues.
<durschatz> B9DE7FD3-5F8E-4786-BE85-773E8F774398-534-0000CE4DEEC657F8
<durschatz> for console all I have is a video and an image snapshot of the error thrown by maas-ipmi-autodetect-tool
<durschatz> do you need these?
<durschatz> or were you looking for dmesh and/or boot.log
<durschatz> of which neither has the thrown error.
<durschatz> dmesg
<roaksoax> durschatz: it would be ideal if you have a console log itself so I can review, but I guess a video of the error thrown would be helpful
<durschatz> video is 65 MB.  how would you like to receive it?
<durschatz> np ill post it on youtube
<roaksoax> durschatz: yeah or put it somewhere that I can watch it via
<durschatz> Console Video Ubuntu Mass Fail to Commission @ https://www.youtube.com/watch?v=bOp_HqSjpvg
<roaksoax> durschatz: i know what the issue is
<durschatz> cool!
<roaksoax> durschatz: the commissioning environment cannot access the internet, and cannot install dependencies it needs to configure the BMC
<durschatz> OK I will check.
<durschatz> Is it the node that cannot access the internet?
<durschatz> Looks like the node can access the internet:
<durschatz> ubuntu@node1-compute:~$ ping 8.8.8.8
<durschatz> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
<durschatz> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=7.17 ms
<durschatz> MAAS also can reach the internet.
<roaksoax> durschatz: oh, I know what this may be about. can you change the power parameters manually on your system, and can you re-try commissioning?
<roaksoax> durschatz: if you've seen just 3/4 days ago, then this is related an issue with the archives/squid that we are tracking down now
<roaksoax> durschatz: we as in ubuntu, provided it is not a maas issue exactly
<durschatz> that sounds like more of the problem I was expecting.
<durschatz> When you say change power parameters on my system manually.  What should I change them to?
<roaksoax> durschatz: do you have the default power params for the BMC ?
<roaksoax> durschatz: the defuatl user/password combination
<durschatz> I am using LAN_2_0 [IPMI 2.0] with login and password
<durschatz> Sorry Andres, I'm not sure what you're asking me to do?  For power type, there is not default to select.
<mup> Bug # opened: 1548387, 1548390, 1548391, 1548394, 1548396
<mup> Bug #1548402 opened: unable to deploy nodes w/ 14.04 and MAAS 1.10 on Xenial <MAAS:New> <https://launchpad.net/bugs/1548402>
<koaps> hi all, does anyone have an ideas why in my virtualbox testing environment for MAAS 1.9.0 (one region, two controllers), the machines on the second controller when using bonds are not getting a default gateway? If I break the bond and use eth0, I get a default gateway, but when using bonds I don't. We have this setup working somewhere else on all physical servers
<durschatz> Thanks Andres, for letting me know you wanted me to set IPMI username to default ADMIN/ADMIN for Supermicro.
<durschatz> I recommissioned the SuperMicro node and this worked in the sense that the node is now in ready state.
<durschatz> What about the KVM node?  It's using Virsh, not IPMI.
<roaksoax> durschatz: In the UI, you can "Add Chassis"
<durschatz> roaksoax: I have that setup and it FAILED_COMMISSIONING on Friday.  Going to quickly re-try to make sure the problem still exists.
<nagyz> roaksoax, is it expected that a maas controller is somehow present on all subnets that I want to deploy machines to? I fear that's a far-fetched requirement, if so. If not, then great, and that means I should just be able to go ahead and add subnets using the CLI, right?
<Razva> [ERROR] Failed to upload leases: 'str' object has no attribute 'mac' < when deploying via Landscape. any hints?
<nagyz> I guess I just have to try this...
<nagyz> or does anybody have some experience with it?
<koaps> nagyz: I think a MAAS controller has to be on any subnet you want PXE on
<durschatz> I second koaps: MAAS needs to be on subnet that the node is looking to PXE on.
<nagyz> right, but it's not about PXE
<koaps> durschatz: you wouldn't have any ideas on my issue would you?
<nagyz> what if I'd like to define different subnets (10.1.1.0/24, VLAN 123), and then PXEboot from something else (172.16.1.0/24, VLAN 333), then set up bond0.123 to a static IP?
<nagyz> surely the controller doesn't have to have an IP on a subnet where we're not PXEbooting from
<nagyz> the boot requirement is obvious :)
<durschatz> I'm not 100% sure.  PXE happens at layer 2
<koaps> nagyz: I do that now, bond0 is native vlan where PXE is and I add in two more bond0.123 bond0.321 fabrics, in that case MAAS has no idea about the subnets on bond0.123 or bond0.321, it just adds the interfaces, you can create subnets for those vlans using the maas commands
<koaps> but MAAS controller doesn't have interfaces on them
<nagyz> ok, great, exactly the info I'm looking for
<nagyz> so the fabric in 1.9+ gives me the L2 domain, basically?
<nagyz> then I need to tie the subnet to a fabric?
<koaps> ya
<nagyz> great, thanks
<nagyz> anything particular to look out for when creating the subnets from the CLI?
<koaps> give me a sec and I can give you the maas commands
<nagyz> koaps, ?:P
<nagyz> ah
<mup> Bug #1548542 opened: maas.drivers.power.ipmi: [WARNING] Failed to change the boot order to PXE <IP>  ipmi_ctx_open_outofband_2_0: BMC busy on Dell 12G servers <oil> <MAAS:Incomplete> <https://launchpad.net/bugs/1548542>
<mup> Bug #1548560 opened: twisted 16 removes deprecated attributes in Request and DummyRequest <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1548560>
#maas 2016-02-23
<mup> Bug #1548560 changed: twisted 16 removes deprecated attributes in Request and DummyRequest <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1548560>
<mup> Bug #1548560 opened: twisted 16 removes deprecated attributes in Request and DummyRequest <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1548560>
<mup> Bug #1548601 opened: Machine attempted to boot on a non-existant image, but it didn't mark as failed <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1548601>
<mup> Bug #1548601 changed: Machine attempted to boot on a non-existant image, but it didn't mark as failed <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1548601>
<mup> Bug #1376483 opened:  AttributeError: 'Port' object has no attribute 'socket' <tech-debt> <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1376483>
<mup> Bug #1548601 opened: Machine attempted to boot on a non-existant image, but it didn't mark as failed <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1548601>
<mup> Bug #1376483 changed:  AttributeError: 'Port' object has no attribute 'socket' <tech-debt> <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1376483>
<mup> Bug #1376483 opened:  AttributeError: 'Port' object has no attribute 'socket' <tech-debt> <MAAS:New> <MAAS 1.10:New> <https://launchpad.net/bugs/1376483>
<imranh> Can anybody help me? I have a sever with 2 interfaces with MAAS running, eth0 is 192.168.202.145/24 and is our main network, eth1 is 192.168.140.1/24. On MAAS i have eth0 set to unmanaged and it just gets dhcp in /etc/network/interfaces, eth1 is statically assigned in that file and under MAAS it does dhcp and dns. I have 5 servers plugged into the switch that eth1 is also plugged into. I can PXE boot, the server will start doing it's t
<imranh> the network info it starts timing out grabbing "'http://169.254.169.254/2009-04-04/meta-data/instance-id'"
<imranh> I've imported the 14.04 LTS amd64 images in maas
<imranh> google leads me to https://bugs.launchpad.net/maas/+bug/1402861 but that doesn't really help
<imranh> Am I better off asking this question elsewhere?
<Razva> hi folks! in MAAS, if I go to Subnets, I see two fabrics: one for WAN and one for LAN (which I suppose it's ok). BUT when I go to Nodes and choose Subnets (from the left sidebar) I can see only the LAN IPs. isn't this wrong?
<imranh> Fixed my problem, i ran dpkg-reconfigure maas-cluster-controller and changed the address from 192.168.202.145 to 192.168.140.1
<Razva> imranh do you have any experience with setting MAAS?
<imranh> Razva: none, sorry. I came on here tryng to setup my first cluster
<Razva> hah, same here :))
<Razva> do you see your public IPs in the Nodes -> Subnets (sidebar)?
<Razva> because I can see only my LAN IPs, which is...weird
<imranh> Razva: I've only just got node enlisting working in my enviroment, before abnout 2 minutes ago i couldn't get anything to enlist
<Razva> need a hand?
<imranh> Razva: Just got it going, need to go down to the server room to switch the machines on now
<Razva> don't. use PXE
<Razva> or at least you should :D
<imranh> Razva: switch the machines on to pxe boot so they appear in the node list is waht i meant
<Razva> oh, ok. from my experience using KVM or iDRAC will be REALLY helpfull. I've installed Ubuntu about 25 times in order to have a fully functional MAAS + Juju + AutoPilot + OpenStack installation.
<Razva> here are my hints
<Razva> 1) DON'T use RAID. just use plain disks, without any kind of raid
<Razva> 2) rename your nics from em1 or eno1 or whatever to eth0 and eth1
<Razva> ^^^ https://github.com/Razva/newbadmin/blob/master/device-management/nic-rename.sh
<Razva> 3) install BIND Cache on your MAAS server if you want to deploy OpenStack or use any kind of networking stuff, as Juju is VERY bad sometimes at DNS (for reasons I cannot explain!)
<imranh> Razva: cheers :)
<imranh> I'm just waiting for access to the server room now
<haasn> imranh: You don't have IPMI? AMT? Even wake-on-lan?
<imranh> haasn: none of it is setup yet, fresh batch of servers
<imranh> I don't even know the cpu model in them
<imranh> All I know is that each one has: 56 threads, 128GB ram, 2x 320 drives, 2x 10G fiber cards and 1x 1G port
<mup> Bug #1548396 changed: 1.9.0 node stuck in broken status <ui> <MAAS:New> <https://launchpad.net/bugs/1548396>
<imranh> woop just got the keys to the server room
<imranh> time to go set these servers up
<mup> Bug #1548396 opened: 1.9.0 node stuck in broken status <ui> <MAAS:New> <https://launchpad.net/bugs/1548396>
<haasn> imranh: You don't have your workstation located in the server room yet?
<mup> Bug #1548396 changed: 1.9.0 node stuck in broken status <ui> <MAAS:New> <https://launchpad.net/bugs/1548396>
<imranh> haasn: If only it was a little bit more quieter
<imranh> haasn: Also the temperature difference a few steps can take is unbelieveable
<haasn> The noise is so monotonous that it's as good as silence, the upside being that it also drowns out any possible audio distractions
<imranh> haasn: :)
<haasn> (Such as coworkers furiously yelling at you)
<imranh> hmmm maas seems to think my servers are on when they are not...
<roaksoax> imranh: wait for a minute or two till maas updates power states
<roaksoax> imranh: maas doesn't do second by second power state update
<roaksoax> imranh: otherwise your BMC may lock up
<imranh> roaksoax: ok :)
<haasn> It's funny when you think about it. The handbook for my servers contains an entire section on what to do if the BMC locks itself up (in various ways)
<haasn> How are we, in 2016, programming work-arounds for BMCs locking themselves up?
<roaksoax> haasn: that's due to the crappy BMC implementations out there!! You'd be surprised how bad sometimes they are :)
<haasn> Imagine if Linux had code to throttle its floating point computations on intel processors to avoid locking up the floating point chip
<haasn> It's just bizarre. How can these companies be _so_ bad at programming their devices?
<haasn> I mean I get that in the case of our servers it's Sun/Oracle writing/maintaining it, and therefore it probably also runs on Java which explains 90% of that crap, but still
<roaksoax> haasn: i guess the lack of rigorous testing against all the interfaces out there ?
<haasn> roaksoax: But even their built-in web interface can lock itself up. You'd think they'd test at least that?
<haasn> It seems like a case of âwell, if the user power cycles the machine it fixes itself so let's just ship it with a line of documentation alluding to thatâ
<roaksoax> haasn: i'm sure they do! You'd imagine that these things, being so important, take more attention, but I guess that shipping so many different firwmare version with so many different systems, takes a toll
<haasn> (They would probably be more stable if they figured out some way of getting BSD-like microkernel + a small existing httpd to run on them instead of writing their own NIH web server :p)
<haasn> Maybe even faster
<roaksoax> hehe
<imranh> https://www.youtube.com/watch?v=GZeUntdObCA a great talk on BMCs
<nagyz> roaksoax, is there a way to deploy currently a node with a bond0 interface without any network associated to it, but have VLAN interfaces on different networks?
<nagyz> I don't seem to be able to click through this via the UI.
<imranh> hmmm the openstack installer is currently telling me i have no machines enlisted with power control
<imranh> Nevermind, me being silly
<imranh> [ERROR: 02-23 16:20:18, ev.py:130] Exception in ev.run(): Traceback (most recent call last):
<imranh> fun
<bbaqar1> Hey guys .. Any
<bbaqar1> Anyone got this bug recently?
<bbaqar1> https://bugs.launchpad.net/maas/+bug/1520645
<bbaqar1> @roaksoak
<roaksoax> bbaqar1: not really
<roaksoax> bbaqar1: what do you see exactly? VM's failing to enlist ?
<bbaqar> Yes.
<roaksoax> bbaqar1: do you have console logs to look ato? maas logs (regiond.log, clusterd.log)
<bbaqar> Which exact logs would you like to see. I can get them once I get access to the setup again.
<roaksoax> bbaqar: 1. console log of the machine trying to enlist 2. regiond.log 3. clusterd.log (the latter 2 around the time you were trying to enlist)
<bbaqar> Okay got it. Will check them out.
<roaksoax> bbaqar: thanks!
<roaksoax> bbaqar: do share1, that will allow to see what may be wrong
<bbaqar> Where to get the console.log of the enlisting node?
<roaksoax> bbaqar: from the console of your enlisting node :
<roaksoax> )
<roaksoax> bbaqar: we don't record that info
<bbaqar> aah i get it. thats what I was confused about. Will get back to you soon.
<bbaqar> thanks.
<bbaqar> roaksoax: Connecting a node to two subnets with both managing DHCP and DNS should not be a problem right?
<roaksoax> bbaqar: that may indeed be the problem dependending on how dhcp is configuring them
<bbaqar> roaksoax: I did disconnect all cables from the node apart from just one but still got the error. Where can I remove all node specific information from in maas? dhcp.leases?
<roaksoax> bbaqar: has the node been added to MAAS ?
<roaksoax> bbaqar: if the node is not added to MAAS then you don't need to worry about dhcpd.leases
<bbaqar> Basically it fails with the following error: "failed to enlist system maas server 'compute.maas'" where compute.maas is the fqdn of a already added node
<bbaqar> no it hasnt. the enlistment was never succesful.
<roaksoax> bbaqar: interesting! so what's happening is that the enlistment is doing a dig to try to find out the hostname
<roaksoax> if theres any
<roaksoax> bbaqar: and tries to enlist it
<roaksoax> bbaqar: do you have an external dhcp server ?
<roaksoax> err
<roaksoax> DNS server ?
<bbaqar> not a dhcp serve.
<bbaqar> i can check if there is dns server running or not.
<bbaqar> but why does it get the wrong hostname
<bbaqar> i mean right at that time its a baremetal node so doesnt really have a hostname
<roaksoax> bbaqar: try this: http://paste.ubuntu.com/15183875/ on /etc/maas/preseeds/enlist_userdata
<roaksoax> bbaqar: and try to re-enslit. That should fix your issue
<bbaqar> Okay cool. so i have to remove those three lines.
<bbaqar> Great I ll try it out soon. Thanks a bunch.
#maas 2016-02-24
<mup> Bug #1549174 opened: Spurious failure in TestDNSDynamicIPAddresses.test_bind_configuration_includes_dynamic_ips_of_deployed_nodes <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549174>
<mup> Bug #1549174 changed: Spurious failure in TestDNSDynamicIPAddresses.test_bind_configuration_includes_dynamic_ips_of_deployed_nodes <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549174>
<mup> Bug #1549174 opened: Spurious failure in TestDNSDynamicIPAddresses.test_bind_configuration_includes_dynamic_ips_of_deployed_nodes <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549174>
<imranh> i'm pretty sure the openstack installer has just hung
<imranh> oh, so doing ^c then looking at commands.log helps
<mup> Bug #1549206 opened: Spurious failure in TestDNSConfigModifications.test_add_node_updates_zone <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549206>
<mup> Bug #1549208 opened: Spurious failure in TestDNSConfigModifications.test_change_node_hostname_updates_zone <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549208>
<mup> Bug #1549210 opened: bin/test.region: BlockingIOError: [Errno 11] write could not complete without blocking <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549210>
<mup> Bug #1549230 opened: Spurious failures in DNS configuration tests <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549230>
<imranh> How long should bootstrapping juju take in the openstack installer because I'm about to hit 30 minutes...
<imranh> so syslog is full of error (network unreachable) resolving 'streams.canonical.com/AAAA/IN': 2001:503:ba3e::2:30#53
<kiko> imranh, it should take 5 minutes longer than provisioning the machine in MAAS
<imranh> kiko: ok so something is wrong
<kiko> imranh, yes, but I'm not sure that error matters unless you are on an IPv6-only network
<kiko> imranh, if you want to kill the bootstrap and re-run with a --debug it will give us better insight
<kiko> imranh, has maas actually provisioned the bootstrap node?
<imranh> kiko: I'm not, i'm on a ipv4 only network here
<kiko> ok
<imranh> I've been running the OS installer with "DEBUG_JUJU_BOOTSTRAP=1 openstack-install"
<imranh> ah
<imranh> it did soemthing
<roaksoax> imranh: juju can't access to streams.canonical.com ? MAAS at no point tries to access streams.canonical.com. That's probably juju trying to access their own streams and failing
<imranh> multi.py:206] Failed to get ip directly: [Errno -2] Name or service not known
<roaksoax> imranh: yeah that's what it seems to be
<kiko> roaksoax, well, but that's an IPv6 query
<imranh> ok
<imranh> so i disabled ipv6 completely inbetween saying i saw those errors in ssylog and it seems to be working now
<roaksoax> kiko: so my understanding with the squid bug is that if it finds a link local address, it iwll try ipv6 first. If the other endpoint has 10+ IPv6 addresses, then squid will fail as it will attempt 10 retires
<roaksoax> kiko: if the endpoint were to have 9 IPv6 and 1 IPv4, the request would go through just fine
<roaksoax> kiko: maybe that's the issue here
<kiko> oh how interesting
<kiko> it's actually a bug?
<roaksoax> kiko: the issue with squid, yes. Because, I guess that squid3 should never try to reach the internet with ipv6 if the machine where it is running only has link local
<roaksoax> kiko: and even if it does, and fails, it never tries IPv4 if the other endpoint has 10+ Ipv6 addresses
<imranh> multi.py:165] Finished MAAS step, now deploying Landscape.
<imranh> woop
<imranh> progress
<kiko> now we're talking!
<kiko> roaksoax, should we ship our squid with ipv6 disabled?
<kiko> roaksoax, and release note that if you are on ipv6 enable it?
<roaksoax> kiko: no, we should ship it ipv6 enabled, but we could default to ipv4 first. However, the issue is being fixed on squid so when the fix lands, the work around won't really matter much
<kiko> ah
<kiko> gotcha
<kiko> is it easy to default to ipv4?
<roaksoax> kiko: yes, just a config option, that would need to get tested first though
<imranh> gui.py:267] A fatal error has occurred: 'NoneType' object has no attribute 'info_message'
<imranh> :(
<imranh> task.py:71] ran off end of task list, can't start Bootstrapping Juju
<kiko> hmm
<kiko> imranh, what version of juju?
<imranh> kiko: should be the latest for 14.04 one sec
<imranh> juju-core 1.25.3
<imranh> trying it all again...
<kiko> imranh, that looks like an honest bug.. in landscape?
<kiko> imranh, I'd like to know what happens before that?
<imranh> kiko: well it ran the landscape configure command with my details that I had entered, then the openstack ui crapped itself (for lack of better phrasing) and i saw those lines in the commands.log file
<imranh> s/openstack ui/the openstack installer ui/
<imranh> I'm trying again now
<imranh> if it happens I'll report a bug
<kiko> hmm
<imranh> But i kinda need to get this setup
<imranh> here we go
<mup> Bug #1549303 opened: DeprecationWarning: twisted.internet.task.LoopingCall.deferred  <MAAS:Triaged> <https://launchpad.net/bugs/1549303>
<mag009> any maintainer online ?
<kiko> yes
<kiko> imranh, it worked? what changed?
<imranh> kiko: just got to the point where it error'd last time
<imranh> SUCESS
<imranh> :D
<kiko> heh
<imranh> Sorry it didn't error again, it'd love to help debug the error i got
<imranh> once i have this setup I might try and reproduce it in a VM
<mag009> question for you kiko , how do I create a partition in curtin to use all the space without specifying a size of a partition
<kiko> imranh, and nothing changed? mm
<kiko> mag009, once you commission you do know the size of the drive
<mag009> how do I pass it to curtin in a variable?
<kiko> mag009, but smoser will know the answer to that question (as might blake_r)
<kiko> it's a good question
<imranh> kiko: I changed nothing apart from wiping the .cloud-install dir after running openstack-install -u
<mag009> from my understanding it's only a template that you hardcode the value which is not dynamic at all.
<mag009> unless i'm missing something
<smoser> mag009, you're wanting to do that with curtin rather than with maas ?
<kiko> smoser, I think so
<mag009> well the device vda from server to server change
<mag009> I'm trying to setup a generic template lvm for all my baremetal
<mag009> sda to be the os in lvm ideally I'd like to be able to use : /dev/sda -> lvm
<smoser> this is maas 1.9 ? or 1.8
<mag009> but as I can see you are not doing a pvcreate
<mag009> so you expect a partition in order to call vgcreate directly
<mag009> It wouldn't be hard tho to add a pvcreate function..
<mag009> it'd like to mention that this is for a custom image :)
<mag009> maas does not support custom image yet for partitioning if I'm not mistaken
<mag009> so thats why I'm using curtin
<kiko> mag009, what do you mean by "custom image for partitioning"?
<mag009> smoser, do you get my idea ?
<smoser> mag009, i do want to have curtin able to do the sorts of things you're after, but at the moment it isn't really well suited for it.
<smoser> what i'd suggest you do is provide curtin config that overrides the 'partitioning' stage, and does whatever you want
<smoser> you can then script that with sgdisk or sfdisk or parted or whatever.
<smoser> this is also not well documented. :-(
<smoser> these are things i'd like to fix, and patches are certainly welcome.
<smoser> but its just not there yet.
<mag009> if I may propose a simple solution :
<mag009> this "/usr/lib/python3/dist-packages/curtin/commands/block_meta.py"
<mag009> just before the vgcreate
<mag009> I'd like to call a pvcreate
<mag009> in this particular case I can use the device in my volume vg
<roaksoax> /in/win 4
<mag009> @smoser this is maas 1.9 ? or 1.8 i'm using maas 1.10
<smoser> :)
<smoser> so with the storage config you shoudl be able to acheive what you want
<mag009> not really
<mag009> I'm looking at it and I must specify a size of my partition
<smoser> it is painful probably, but you can go to each node and use that ui to cofigure as you'd like.
<mag009> but again I'm using a custom image..
<mag009> which is not supported by the ui
<mag009> right ?
<roaksoax> mag009: custom image deployment od not get storage/network config no
<mag009> here's my problem that I have : size: 0B if I set the size to zero which is what I want to pass to sgdisk
<mag009> 'sgdisk', '--new', '1:2048:2047', '--typecode=1:8300', '/dev/vda'
<mag009> I want to have 1:2048:0
<mup> Bug #1549331 opened: Spurious failure in TestPXEConfigAPI.test_pxeconfig_returns_json <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549331>
<mag009> I'd like to have your input I can submit a patch but if you can tell me if its okay with you
<mag009> i'd like to do an exception : if you enter a size of : 0B  = use all the device space
<mag009> and skip the following : length_sectors + offset_sectors
<kiko> smoser, ^^ mag009
<mag009> ?
<mag009> i tested my patch and it does work
<smoser> roaksoax, custom image deployment really should still get sotrage config
<smoser> whether or not it applies it should be beyond maas's care.
<smoser> mag009, oh. i see.l
<roaksoax> smoser: is there code in curtin to ensure that the config does not apply ?
<smoser> i dont like '0' there being the size. we really should support some way of doing that.
<smoser> but i dont knwo that 0 is right.
<mag009> how you want to exclude it :)
<mag009> 100% ?
<mag009> size: 100%
<mag009> i dont understand why you chose to use sgdisk vs parted
<mag009> cause in the case of parted we could of used the percentage straight into the size value
<roaksoax> smoser: since if we send the storage config, curtin will apply it regardless of the machine. So MAAS doesn't send it to ensure that curtin does things the old way
<smoser> i do want to support % at some point in some way.
<smoser> roaksoax, yeah. but then it woudl be possible for the image you provide dto have curthooks that would actuallyw ork
<smoser> and by not sending it you're explicitly dis-allowing that.
<mag009> I just need how you want that.. so my patch get approved..
<mag009> lol
<roaksoax> smoser: right, but if we send the config, curtin will still try to partition. Either way, MAAS does not support doing custom partitioning/networking for custom images, nor other OS's
<smoser> but you (or we) shoudl have implemented that better.
<smoser> mag009, you can proposed the change to curtin if you want. it wil make us think about it.
<mag009> my problem is it's a core feature required by our environment
<mag009> and i believe it won't happen quickly if I propose something ;)
<mag009> I dont mind coding that part if I know what you guys have in mind for that.
<kiko> mag009, I think what smoser is saying is a) do the patch b) put it in the bug and c) we'll look at it for inclusion, possibly proposing a slight change in the config
<kiko> mag009, so you should be unblocked for now -- smoser can roll out a new curtin release easily once that's done
<mag009> yes Its what I concluded thx
<mag009> finally I got a debian install with lvm partition like I wanted
<mag009> :D
<kiko> mag009, rook
<mup> Bug #1549397 opened: Spurious failure in TestStaticIPAddressManagerMapping.test_get_hostname_ip_mapping_returns_raw_ttl <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1549397>
<mag009> is it possible to migrate one maas to another ?
<mag009> is there a script to do that?
<mag009> maas v 1.9 -> 1.10
<roaksoax> mag009: you mean upgrade from 1.9 to 1.10 ? you can do that if you wanted to upgrade to xenial
<roaksoax> mag009: 1.10 is just basically maas 1.9, but running with django 1.8 and python3
<mag009> i have 2 maas installation
<mag009> I want to import from my other maas instance which is v1.9
<mag009> to my new one 1.10
<roaksoax> mag009: ah, so we dont have a migration script because we support upgrade path
<dbainbri> using 1.8.0, attempting to update the 'name' of a node-group via REST using the maasclient Python module. the put is returning 200 OK, by the name is not being updated? nothing in the logs, thoughts?
<kiko> roaksoax, isn't that a known problem ^^
<roaksoax> kiko: no, but there amy be related to it updating the dns name instead ?
<kiko> hmm
<mup> Bug #1549478 opened: DNS Forwarders not being added to bind configuration <dns> <forwarders> <maas> <named.conf.options> <MAAS:New> <https://launchpad.net/bugs/1549478>
<nagyz> roaksoax, is it possible to configure bond0 without configuring any subnet on it, and then have just vlan interfaces under?
<roaksoax> nagyz: you should be able to have this for example:
<roaksoax>  bond0 fabric0 untagged subnet1 Unconfigured
<roaksoax> bond0.1 fabric0 vlan1 subnet2  AutoAssign
<nagyz> generally or via the GUI as well?
<nagyz> ah I see I need to configure subnet1 on it - that's where the confusion is coming from
<nagyz> on a trunk interface it doesn't make sense for a bond interface to belong to a subnet
<nagyz> especially if I want subnet1 to be on bond0.1
<roaksoax> nagyz: yeah
<roaksoax> nagyz: right, but it will still be unconfigured, but you could also put bond0.1
<roaksoax> nagyz: if you set the subnet as unconfigured, it does not allow you to create a bond ?
<roaksoax> err a vlan interface
<nagyz> hmm, I could have sworn that it doesn't let me
<nagyz> but just tried it, and it works.
<nagyz> one more question: in some cases we see a node that we wanted to redeploy (after a release) booting into the previously deployed OS instead of doing a proper PXE boot
<nagyz> and going into the BIOS tells us that the order didn't change
<nagyz> should release reset the bios disk order?
<nagyz> also it seems kinda redundant to select a VLAN then a subnet
<nagyz> while the subnet is tied to vlan...
<nagyz> right now I cannot put the same interface both untagged and tagged to different nodes, even though they would be the same subnet, can I, roaksoax ?
<renuka> help
<renuka> The nodes leaving behind in the power error state after the nodes are commissioned and changed to ready state.
#maas 2016-02-25
<renuka> issue with MAAS trying to connect to your system BMC
<renuka> can anyone please help me wit that
<mup> Bug #1549566 opened: [2.0] When the Primary Rack controller cannot connect to the Region Controller, DHCP is not disabled / no fail over <MAAS:Triaged> <https://launchpad.net/bugs/1549566>
<mup> Bug #1549670 opened: When ControllersManager updates its list, it can include non-controller objects <MAAS:Triaged> <https://launchpad.net/bugs/1549670>
<mup> Bug #1549670 changed: When ControllersManager updates its list, it can include non-controller objects <MAAS:Triaged> <https://launchpad.net/bugs/1549670>
<mup> Bug #1549670 opened: When ControllersManager updates its list, it can include non-controller objects <MAAS:Triaged> <https://launchpad.net/bugs/1549670>
<mup> Bug #1549842 opened: [2.0] Failed to update this region's process and endpoints; unleashed:pid=28940 record's may be out of date <MAAS:New> <https://launchpad.net/bugs/1549842>
<mup> Bug #1549843 opened: [2.0] Failed to update this region's process and endpoints; unleashed:pid=28940 record's may be out of date <MAAS:New> <https://launchpad.net/bugs/1549843>
<mag009> do you guys have a list of variables like these that we can use in curtin template{{node.system_id}}
<kiko> mag009, hmm, well, the source does? :)
<mag009> wish there was a doc somewhere... instead of having to go through the source ;)
<kiko> smoser is a source-is-docs kind of guy
<kiko> but yes, this is a frequent request I think
<kiko> lborda, deu certo?
<smoser> mag009, doc is horribly lacking :-(
<smoser> the curtin template there that he's referring to though is maas
<smoser> kiko,
<kiko> oh
<mag009> yes I know it's lacking :) basically what I'm trying to figured out is how can I detect if it's a uefi or not so I can apply the boot/efi partition when it is
<kiko> smoser, I wonder if our template vars are documented either :-/
<kiko> roaksoax, do you know?
<mag009> {{bios_boot_method}} seem that it doesn't work in my template
<kiko> mag009, is it used in other templates?
<roaksoax> kiko: i had them documented somewhere... i'll look into it
<mag009> no its not
<mag009> {{if bios_boot_method == "uefi" }} is what I'm trying to achieve :)
<roaksoax> mag009: bios_boot_method is definitely something we won't expose in the templates
<roaksoax> mag009: what are you trying to do  ?
<mag009> I'm trying to statically set a  storage in my curtin_userdata_custom
<roaksoax> mag009: maas automatically detects whether you are booting with UEFI or not and performs things in a different way
<mag009> yes for ubuntu
<mag009> I'm trying to make it work for debian Jessie
<kiko> that'd be great for us to get working in fact
<mag009> the uefi is a bit different on debian vs ubuntu
<mag009> slightly ...
<roaksoax> mag009: that is not done on preseeding actually
<mag009> provisioningserver/boot/uefi.py is where you auto detect it
<roaksoax> mag009: all UEFI related stuff on custom images would need to be done on curtin hooks
<mag009> ok if I use a curtin hooks will curtin handle the installation of the grub2-efi package ?
<mag009> I can see the curtin hooks of centos for example but I dont see any package installation
<roaksoax> ltrager: ^^
<mag009> and if i use the curtin hook i believe I cannot preconfigure my storage in the template ?
<roaksoax> mag009: no, we don';t support storage/network config for custom images
<mag009> well for a debian image legacy boot it work fine..
<mag009> its just that your provisioningserver/boot/uefi.py  is trying to install shim which doesnt exist in debian
<roaksoax> blake_r: you have an example of curtin hooks handling UEFI on any custom images ?
<mag009> i have the centos hook thats the one I'm looking at
<mag009> but honestly guys it would'nt be too hard to support debian as well
<roaksoax> mag009: we take patches :)
<roaksoax> mag009: the key here is the images themselves
<mag009> root.tar.gz wouldn't work  ? or you need the following structure : http://maas.ubuntu.com/images/ephemeral-v2/daily/xenial/amd64/20160223.1/
<mag009> ?
<mag009> ok if i look at centos http://maas.ubuntu.com/images/ephemeral-v2/daily/centos70/amd64/20141129_01/
<mag009> its a tgz but I guess it use the curtin hook
<mag009> its not supported officially i guess ?
<kiko> it should be if I understand your question
<kiko> blake_r is the man to answer
<roaksoax> mag009: the image streams is different to when adding a custom image
<roaksoax> mag009: adding a custom image you are basically telling MAAS it is a tgz
<mag009> yes ok thats what I thought
<roaksoax> mag009: but the curtin hook is what is used to do other things for those images themselves
<mag009> so the centos in your repo is basically a custom image
<roaksoax> mag009: it is centos + custom curtin hooks bits
<roaksoax> mag009: the only different is the curtin hooks
<roaksoax> difference*
<mag009> ok
<mag009> i'll try with the curtin hook
<ltrager> mag009: we normally prebake all the packages we need into the image before deploying incase the machine can't access the repositories. However you could shell out from the curtin script to run apt/yum/dnf etc
<ltrager> mag009: also grub-efi is a meta package in Ubuntu/Debian it may be called something else on CentOS
<ltrager> mag009: nm it looks like it does have grub2-efi
<mag009> ltrager  the package is there but it failed at the installation of shim and grub-efi-amd64-signed
<mag009> because on debian these do not exist
<ltrager> are you getting the grub2-efi package from the Debian archive? According to package.debian.org it only depends on grub-efi-amd64 - https://packages.debian.org/jessie/grub-efi
<mag009> i know but when it deploy the curtin failed because it try to install these extra pacakges
<mag009> which is auto installing from the boot/uefi.py
<mag009> I can write an exception for Debian not to install these 2 packages its not a big deal
<aka> help:
<aka> unable to download mass, showing depnd error
<aka> unmet dependencies: libcogl15 libegli1-mesa-drivers
<roaksoax> aka: we don't; install those dependencies nor depend on them
<roaksoax> aka: those seem like something unrelated
<aka> how to solve this issue?? any alternate
<roaksoax> aka: sudo aptitude upgrade ? does that even help?
<aka> it worked but now its letting me create admin
<aka> it says command not found for creating admin
<roaksoax> aka: sudo aptitude install maas
<roaksoax> sudo maas-region-admin createadmin
<aka> command not found
<aka> while checkin maas it says no argument given
<roaksoax> aka: dpkg -l | grep maas
<roaksoax> what's the output of that
<aka> maas cli
<aka> python mass client
<roaksoax> aka: then you are missing packages
<roaksoax> aka: the 'maas' package is not installed
<aka> that's the only issue...its showin unmet dpnds error again...
<aka> tried aptitude but coundnt get maas...
<roaksoax> aka: do you have an output where we can see? Where are you trying to install maas from ?
<roaksoax> aka: what release ?
<aka> from maas website...
<aka> pt-get to aptitude  Action 	  apt-get command 	  aptitude command  Install foo 	  apt-get install foo 	  aptitude install foo  Search foo 	  apt-cache search foo 	  aptitude search foo  Remove foo 	  apt-get remove foo 	  aptitude remove foo  List reverse dependencies 	  apt-cache rdepends foo 	  aptitude search ~Dfoo  Print information on priorities for foo 	  apt-cache policy foo 	  aptitude versions foo
<aka> Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:  The following packages have unmet dependencies:  libcogl15 : Depends: libegl1-mesa-drivers  maas : Depends: maas-cluster-controller but it is not goin
<aka> The following packages have unmet dependencies:  libcogl15 : Depends: libegl1-mesa-driver
<kiko> aka, you are deep in PPA hell
<roaksoax> aka: yeah but what PPA ?
<aka> sudo add-apt-repository ppa:maas/stable
<kiko> aka, what I mean is that you have other PPAs that have messed up your system
<kiko> you will need to do a good old apt-get -f install
<kiko> and see if that helps things
<kiko> it will probably uninstall your X server
<kiko> sounds like you've got xorg edgers or something crazy like that
<roaksoax> indeed
<aka> same error again
<kiko> aka, essentially, your distro is broken
<kiko> you will need a fresh ubuntu or install maas into a container
<aka> is there any repair thing?
<aka> my sys also stopped accepting updates
<kiko> heh
<mup> Bug #1550060 opened: Settings page 'Users and Keys | Last seen' should show 24-hour enGB formatted datetime <MAAS:Triaged> <https://launchpad.net/bugs/1550060>
#maas 2016-02-26
<roaksoax> bzr l/win 4
<mup> Bug #1550080 opened: [2.0] Bad error messages when failing to add a chassis, it is too raw <MAAS:Triaged> <https://launchpad.net/bugs/1550080>
<mup> Bug #1550081 opened: [2.0] No error message is displayed when failed to add a domain <MAAS:Triaged> <https://launchpad.net/bugs/1550081>
<mup> Bug #1550083 opened: IP-based hostname concatenated with a string is not accepted. <MAAS:New> <https://launchpad.net/bugs/1550083>
<mup> Bug #1550435 opened: boot sector signature not found on first boot after deploy on raid array <MAAS:New> <https://launchpad.net/bugs/1550435>
<mup> Bug #1550435 changed: boot sector signature not found on first boot after deploy on raid array <MAAS:New> <https://launchpad.net/bugs/1550435>
<mup> Bug #1550435 opened: boot sector signature not found on first boot after deploy on raid array <MAAS:New> <https://launchpad.net/bugs/1550435>
<mup> Bug #1550510 opened: 1.9 UI Take action "Go" button for (re)commissioning a node with customized storage doesn't trigger the action <MAAS:Incomplete> <https://launchpad.net/bugs/1550510>
<mup> Bug #1550540 opened: DNS test suite needs to do better lockstep on checking that DNS updates happened <MAAS:New for lamont> <MAAS 1.10:New for lamont> <MAAS trunk:New for lamont> <https://launchpad.net/bugs/1550540>
<mimizone> hi all. I am looking at Maas to install openstack. Can somebody point me to the documentation that would detail the level of control available for the networking at the hardware level? We use IP ranges per rack which typically requires custom config of the DHCP server, and would like to limit the number of physical ports and also VLANs. Maybe there is even a way to put a level of QoS on some vlan (like storage) and still use one si
<mimizone> ngle NIC?
#maas 2016-02-27
<mup> Bug #1550616 opened: API 2.0 cleanup <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1550616>
<mup> Bug #1550616 changed: API 2.0 cleanup <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1550616>
<mup> Bug #1550616 opened: API 2.0 cleanup <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1550616>
<mup> Bug #1550644 opened: [2.0] Rack Controller interface parsing shouldn't only rely on e/n/i <MAAS:New> <https://launchpad.net/bugs/1550644>
<mup> Bug #1550645 opened: [2.0] Cluster doesn't allow to add interfaces dynamically <MAAS:New> <https://launchpad.net/bugs/1550645>
<ElectricBlue> hello?How dose this work?
<rsanni> hi
<rsanni> i have deployed the maas i need to add nodes to cluster
<rsanni> please provide me alink to do so
<bbaqar1> https://maas.ubuntu.com/docs/nodes.html
<bbaqar1> Do edit cluster master before
#maas 2016-02-28
<rsanni> hi
<nagyz> how the heck can I delete a subnet? :S
<nagyz> or update it...
<nagyz> roaksoax? :)
<nagyz> some pgsql magic did the trick...
#maas 2017-02-20
<mup> Bug #1666096 opened: update maas from 2.0 to 2.1 <MAAS:New> <https://launchpad.net/bugs/1666096>
<mup> Bug #1666097 opened: update maas from 2.0 to 2.1 <MAAS:New> <https://launchpad.net/bugs/1666097>
<mup> Bug #1666165 opened: Problems with maas-dhcp <MAAS:New> <https://launchpad.net/bugs/1666165>
<mup> Bug #1650587 opened: [FUJ]  It is not clear for users that they need to click on 'Save Selection' to start importing new images <MAAS:New> <https://launchpad.net/bugs/1650587>
<mup> Bug #1650587 changed: [FUJ]  It is not clear for users that they need to click on 'Save Selection' to start importing new images <MAAS:New> <https://launchpad.net/bugs/1650587>
<mup> Bug #1650587 opened: [FUJ]  It is not clear for users that they need to click on 'Save Selection' to start importing new images <MAAS:New> <https://launchpad.net/bugs/1650587>
<Flint_> Hi guys!
<Flint_> quick question
<Flint_> Do you plan to release the windows imaging tool for MAAS soon?
<pmatulis> Flint_, currently, non-Ubuntu/CentOS and any type of custom image requires a commercial agreement with canonical
<Flint_> pmatulis: ok, nice.
<Flint_> pmatulis: I'm currently able to generate a usable windows image for MAAS but I have to use a windows machine, and I know that canonical have a linux tool ^^
<brendand> Flint_, i'm not 100% sure but i don't think a windows image can be generated on linux - might be that creation of the image requires some closed source binaries or suchlike
<Flint_> brendand: it use kvm ;-)
<Flint_> with nested virtualization
<brendand> Flint_, that would still be running a windows image, right?
<Flint_> yep
<brendand> Flint_, which is not something that can just be shipped around...
<brendand> Flint_, anyway, where did you see about the tool?
<Flint_> brendand: on the Cloudbase website :D
<brendand> Flint_, right - it's says 'stay tuned' :)
<Braven> hello all
<Flint_> brendand: yep, that's why I ask as it was on 2014
<brendand> Flint_, there might be something but as per what pmatulis it requires a commercial agreement
<Flint_> brendand: yep, that's why I'll contact canonical :D
<brendand> Flint_, through https://maas.io/contact-us ?
<Flint_> nop I've got professional contact to our partnership.
<brendand> Flint_, cool
<Flint_> ok, I've got to go, see you folks
<mup> Bug #1666274 opened: MAAS HA broken URL <maas-at-home> <MAAS:New> <https://launchpad.net/bugs/1666274>
<mup> Bug #1666165 changed: Problems with maas-dhcp <MAAS:Invalid> <https://launchpad.net/bugs/1666165>
<mup> Bug #1666317 opened: Colour scheme changes in 2.2 beta2 make the UI worse <MAAS:New> <https://launchpad.net/bugs/1666317>
<mup> Bug #1666317 changed: Colour scheme changes in 2.2 beta2 make the UI worse <MAAS:New> <https://launchpad.net/bugs/1666317>
<mup> Bug #1666317 opened: Colour scheme changes in 2.2 beta2 make the UI worse <MAAS:New> <https://launchpad.net/bugs/1666317>
#maas 2017-02-21
<mup> Bug #1666343 opened: would be nice if controller page linked to logs <maas-at-home> <MAAS:New> <https://launchpad.net/bugs/1666343>
<mup> Bug #1627016 changed: [2.1, rev5385] MAAS reports there are missing rack connections but no error logs <uosci> <MAAS:Triaged> <https://launchpad.net/bugs/1627016>
<chaithu> Hi All,
<chaithu> need some help regading DHCP when PXE booting a Hardware using MAAS
<chaithu> Problem: HW fails to to get the DHCP IP address when booting up the Linux image . Initial Bootp/DHCP request goes though fine.
<chaithu> after digging with packet capture on MAAS server. we found that there are multiple DHCP servers and they are sending  DHCP NAK being sent by the not serving DHCP servers.
<chaithu> So PXEclient was able to process the correct ACK request ignoring other  NAK requests
<chaithu> But the Linux ipconfig client using by the linux image was not able to do the process the correct DHCP ACK request (There are multiple DHCP NAK packets from not serving servers)
<kklimonda> how do I disable (and keep disabled) dnssec in MAAS?
<kklimonda> ah, it's in settings
<mup> Bug #1666448 opened: [Device Discovery] The "Discovery Enabled" label is a bit confusing <MAAS:New> <https://launchpad.net/bugs/1666448>
<mup> Bug #1666448 opened: [Device Discovery] The "Discovery Enabled" label is a bit confusing <MAAS:New> <https://launchpad.net/bugs/1666448>
<mup> Bug #1666478 opened: Feature Request Allow grub to multi-boot MAAS images <MAAS:New> <https://launchpad.net/bugs/1666478>
<mup> Bug #1666521 opened: MAAS does not detect RAM in newly commissioned VMWARE VM's <MAAS:New> <https://launchpad.net/bugs/1666521>
<eeemil> What is the difference between fabric and space?
<roaksoax> eeemil: fabric is a or a set of switches (contains vlans)
<roaksoax> eeemil: a space is a set of subnets that can communicate with each other via L2
<ybaumy> my ens192 interface isnt getting configured by cloud-init when commissioning. therefor i have no internet connection and the commissioning fails. the ens192 interface is getting the ip from a different dhcp server. is this a problem?
<ybaumy> or is it something else then cloud-init. im kinda lost. i dont know where to start. how are network interfaces configured?
<ybaumy> i figured that i have to setup on the nodes screen each individual node for itself which network the interface should be set
<ybaumy> lets see how the commissioning goes
<vogelc> What is the maas cli command to "acquire" or "allocate" a machine to a user?
<roaksoax> vogelc: maas <user> machines allocate
<mup> Bug #1665839 opened: Compose sometimes composes machines with the same node_id <MAAS:In Progress by newell-jensen> <MAAS RSD :In Progress by newell-jensen> <https://launchpad.net/bugs/1665839>
<mup> Bug #1666698 opened: rackd not generating a dhcpd.conf in a timely manner  <MAAS:New> <https://launchpad.net/bugs/1666698>
<mup> Bug #1666700 opened: maas allocating new IP to existing MAC/IP pair when old IP is free <MAAS:New> <https://launchpad.net/bugs/1666700>
<stormmore> hmmm am I missing something or is there no documentation on enabling https for the UI / API?
<pmatulis> stormmore, there was a thread on that recently on the maas-devel m/l
<stormmore> pmatulis, thanks will go digging
<mup> Bug #1666719 opened: [2.1.3] A node enlistment fails to contact metadata service <MAAS:New> <https://launchpad.net/bugs/1666719>
#maas 2017-02-22
<mup> Bug #1666700 changed: maas allocating new IP to existing MAC/IP pair when old IP is free <MAAS:Invalid> <https://launchpad.net/bugs/1666700>
<kklimonda> if I want to change APT mirror that is used during MAAS deployment. do I have to edit image?
<kklimonda> Juju changes sets mirrors itself, but only for the ephemeral system it seems
<kklimonda> and the target system defaults to archive.ubuntu.com
<eeemil> roaksoax: thanks! :)
<ybaumy> hmm 169.254.169.154 cannot be reached while commissioning
<ybaumy> what is that
<ybaumy> 254
<ybaumy> ok figured that one out. had to reconfigure the region controller and add the correct ip
<ybaumy> so now the commissioning hangs at the apt update with Ign:1 ... messages
<ybaumy> ok i just have to wait for 10 minutes until this is progressing? why
<ybaumy> for the first time in 2.2 beta i now have a ready node. can now deploy
<ybaumy> great just 3 days
<ybaumy> how to lower the timeout values for those apt Ign: messages
<ybaumy> its like taking forever
<ybaumy> Ign:76 failed deployment
<ybaumy> ;)
<ybaumy> nice
<ybaumy> tell is this normal to wait for each Ign message 5 minutes
<ybaumy> no wonder that this doesnt finish
<mup> Bug #1666852 opened: apt IGN messages timeout very high causes failed commissioning and deployment <MAAS:New> <https://launchpad.net/bugs/1666852>
<ybaumy> its the proxy
<ybaumy> somehow the proxy has very high response times or timeout values
<mup> Bug #1533555 changed: [doc] MAAS docs do not say how to set the default gateway for a node <docteam> <maasgh> <MAAS:Invalid> <MAAS 1.9:Invalid> <https://launchpad.net/bugs/1533555>
<mup> Bug #1666997 opened: MAAS fails to enlist new nodes <MAAS:New> <https://launchpad.net/bugs/1666997>
<mup> Bug #1667141 opened: [FFe] Standing FFe for MAAS 2.2 <maas (Ubuntu):New> <https://launchpad.net/bugs/1667141>
<mimizone> Hi all. is there a way to limit Discovery to a specific interface?
#maas 2017-02-23
<mup> Bug #1667267 opened: [RSD] Deleting a machine directly still leaves it composed in the pod <rsd> <MAAS:New> <https://launchpad.net/bugs/1667267>
<mup> Bug #1667426 opened: [2.x] Custom driver support has been broken since the move to Python 3 <MAAS:Triaged> <https://launchpad.net/bugs/1667426>
<mup> Bug #1667426 changed: [2.x] Custom driver support has been broken since the move to Python 3 <MAAS:Triaged> <https://launchpad.net/bugs/1667426>
<mup> Bug #1667426 opened: [2.x] Custom driver support has been broken since the move to Python 3 <MAAS:Triaged> <https://launchpad.net/bugs/1667426>
<mimizone> Hi all.
<mimizone> is there a way to provide the tags directly when creating a machine on the CLI? maas xxx machines create
<brendand> mimizone, no
<mimizone> what about not automatically commissioning the node when created? I don't see such an option on the CLi "machines create". They idea is to be able to add specific tag that are needed for the boot.
<brendand> mimizone, it shouldn't automatically commission
<mimizone> it did
<mimizone> maas ubuntu machines create nodegroup='yes' name=osv16ocp1c architecture=amd64/generic hostname=osv16ocp1c power_type=ipmi power_parameters_power_address=172.30.0.138 power_parameters_power_user=admin power_parameters_power_pass=admin mac_addresses=08:9e:01:ab:fc:f6
<brendand> mimizone, what version?
<mimizone> MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)
<brendand> roaksoax, have you seen that? maybe crept in with rsd
<brendand> but rsd isn't in 2.1 is it?
<roaksoax> brendand: no
<roaksoax> brendand: 'nodegroup' -> that no longer exists in 2.x
<brendand> roaksoax, seems it's the case that adding a machine starts commissioning automatically...
<brendand> i just tried it
<mimizone> thanks for confirming
<brendand> it might be intentional though - if inconvenient
<mimizone> would be great to be an option on the CLI to allow me to add the tags to the nodes before commissioning
<brendand> roaksoax, ^ what do you think?
<brendand> mimizone, i'd say file a bug. personally i'd love that as it would remove a dozen or so lines from some tests i wrote :)
<mimizone> ahah :)
<roaksoax> brendand: adding a machine does start commissioning automatically
<roaksoax> mimizone: you can add tags at any time IIRC
<roaksoax> brendand: adding a machine without commissioning is useless in MAAS
<mimizone> roaksoax: so the tags parameter exists for the machines create command I guess
<brendand> roaksoax, true, but if the machine requires some tweaks to commission..
<mimizone> the "machines create" command didn't take the tags parameter unfortunately
<roaksoax> ah ok, so you would want a machines create XYZ tags=one,two,three
<mimizone> yep
<mimizone> oen reason, making sure the console tty are redirected properly on some machines (depending on the biox setup)
<mimizone> another reason, passing modprobe parameter to make sure the machine reboots properly because of possible bug
<mimizone> I created 2 tags for those cases
<mimizone> so far I use the genral boot parameter for all the machines, but I don't like that approach at all
#maas 2017-02-24
<mup> Bug #1667574 opened: default gateway not set when deploying a machine with two interfaces in same network <MAAS:New> <https://launchpad.net/bugs/1667574>
<mup> Bug #1667633 opened: Digital Loggers Inc. PDU configurations are dependent between machines <MAAS:New> <https://launchpad.net/bugs/1667633>
<neteng> Can someone point me in the general direction for creating of custom images?  Do I build my machine out, make all the changes I need and then somehow tar it up?  Or?
<neteng> I found instructions on building out maas-image-builder (which were broke).  I finally got it installed on my maas machine.
<brendand> neteng, what kind of custom images?
<neteng> just a centos 6.8 64 bit machine...
<neteng> we have lots of custom file changes
<brendand> neteng, CentOS 7.0 won't do (or 6.6)?
<neteng> nope must use 6.8
<brendand> neteng, you need a commercial agreement for anything else
<brendand> Ubuntu and CentOS 7.0/6.6 are the only ones supported by default
<neteng> commercial as in I need to buy support for maas?
<brendand> neteng, yeah
<neteng> there is no other method to making an image?
<brendand> neteng, not that is supported
<brendand> it's oss so obviously if you can convince it to work...
<neteng> okâ¦ not really looking for it to be supported.  Just looking to be able to create my centos 6.8 image that we roll to all of our machines
<brendand> neteng, there's info on pricing on https://maas.io/
<brendand> neteng, i understand
<neteng> it says free for cent and custom images
<brendand> neteng, yes - stock 6.6 and 7.0
<brendand> that could be clarified i guess
<neteng> so there is truly no other way to make an image without paying for support?
<brendand> no
<neteng> lolâ¦ this has gotta be a joke
<brendand> https://docs.ubuntu.com/maas/2.1/en/installconfig-images
<brendand> The CentOS bit should be clarified...
<brendand> ..in order to build a custom image for any operating system is the relevant part
<neteng> Thanks for the help brendandâ¦ time to find a truly open sourced product
<rbasak> I fail to see how this means that MAAS isn't open source. brendand is just declining to spend *his* time on your problem, that's all.
<rbasak> <brendand> it's oss so obviously if you can convince it to work...
<neteng> most openen sourced products have docs that detail how to do what the product is supposed to do
<neteng> I only asked for someone to point me in that direction I did not ask for him to do it for me
<rbasak> I fail to see how this means that MAAS isn't open source.
<neteng> The open sourced products I generally use don't require some sort of paid support to get them working either
<rbasak> And MAAS does what it is advertised to do without requiring any paid support either. The only error here is that the documentation doesn't make it clear what versions it is designed to work with, which has been acknowleged.
<neteng> anywaysâ¦.
<DesktopMan> Running maas on 16.04, trying to commision nodes. commissioning fails with "Can not apply stage config, no datasource found!"
<DesktopMan> any ideas where to start looking for the cause?
<DesktopMan> here's a screenshot of the boot: https://snag.gy/yhbscG.jpg
<pmatulis> looks like an iscsi problem. network?
<DesktopMan> well the network is exceptionally simple... not sure what can go wrong here.
<DesktopMan> thinking it might be this? https://bugs.launchpad.net/maas/+bug/1582323
<DesktopMan> they did commission last week when I was messing around, so that part fits
<DesktopMan> is it possible to log in to the node when it fails commissioning? going to be hard to get logs if not...
<brendand> DesktopMan, you can access the remote syslog from /var/log/maas/rsyslog
<DesktopMan> aha. that is very useful :)
<DesktopMan> the folders there are timestamped two days ago
<DesktopMan> I deleted it and it also fails to enlist.
<DesktopMan> does maas use the cloud image for enlisting/commissioning as well? wondering if the bug above is fixed in those images
<DesktopMan> I did rename the machines inside maas. don't think that should matter
<mup> Bug #1667754 opened: Deleting machines from Nodes listing page tries decomposing multiple times. <MAAS:Triaged> <MAAS RSD :Triaged> <https://launchpad.net/bugs/1667754>
<mimizone> I am a bit confused by how the network gateway/routes are set up via the UI. I use MAAS 2.1. Should there be only one gateway in one subnet? Is there a way to have different setup on different nodes?
<mup> Bug #1667754 changed: Deleting machines from Nodes listing page tries decomposing multiple times. <MAAS:Triaged> <MAAS RSD :Triaged> <https://launchpad.net/bugs/1667754>
<DesktopMan> mimizone: if I understand it correctly you'll have to put the nodes on different lans (physical or vlan) for that since the gateway is configured per subnet
<DesktopMan> for the network interface used for pxe booting that is. after the machine is up you can configure the other interfaces on the node configuration screen
<mup> Bug #1667754 opened: Deleting machines from Nodes listing page tries decomposing multiple times. <MAAS:Triaged> <MAAS RSD :Triaged> <https://launchpad.net/bugs/1667754>
<DesktopMan> https://docs.ubuntu.com/maas/2.1/en/troubleshoot-faq
<DesktopMan> tried to inject a user like it says here, but the image is not called root-image in my /var/lib/maas. changed name+
<DesktopMan> ?
<mup> Bug #1667267 changed: [RSD] Deleting a machine directly still leaves it composed in the pod <rsd> <MAAS:Invalid by newell-jensen> <MAAS RSD :Invalid by newell-jensen> <https://launchpad.net/bugs/1667267>
<DesktopMan> well I give up. no idea how I can find out what goes wrong.
<DesktopMan> same error when trying to enter rescue mode
<DesktopMan> what should I give dpkg-reconfigure maas-region-controller ?
<DesktopMan> it accepts both network addresses and ip addresses....
<pmatulis> i've always used an ip address. by network address i presume you mean a hostname
<DesktopMan> I mean like 10.1.5.0/24
<DesktopMan> doesn't look like it cares what it gets, I think that was my issue
<pmatulis> ohh
<mimizone> maas 2.1 doesn't add gateways, nor static routes. I use static IPs on my interfaces. How can I set the gateway info and my custom routes??
<mimizone> I entered the info in the subnets.
#maas 2017-02-25
<mimizone> part of an answer to my previous question. If there is multiple static routes, the generated /etc/network/interfaces file is not valid.
<mimizone> the pre-down and the post-up lines are not separated by a next line character.
<mimizone> like the following is on one line
<mimizone> pre-down route del -net 172.30.80.0 netmask 255.255.248.0 gw 172.30.80.129 metric 0 || truepost-up route add -net 172.30.72.0 netmask 255.255.248.0 gw 172.30.72.129 metric 0 || true
<pmatulis> mimizone, sounds like you found a bug. kindly file it here: https://bugs.launchpad.net/maas/+filebug
<mimizone> pmatulis: done here https://bugs.launchpad.net/maas/+bug/1667863
<mimizone> I have found another one I think regarding the missing default gateway.
<mimizone> it appears that if I use only bridges instead of physical interface or just VLAN interfaces, the gateway is not set
<mup> Bug #1667863 opened: if a subnet has multiple static routes, the network interfaces file is invalid <MAAS:New> <https://launchpad.net/bugs/1667863>
<mup> Bug #1660860 opened: mdadm error message during 14.04 deploy <MAAS:Confirmed> <https://launchpad.net/bugs/1660860>
#maas 2017-02-26
<candyban> Is it me or is MAAS just a POS ? (I just spent 12h getting the damn thing to provision a single machine and it boots with some sort of error). Even the bootstrap of the original machine does not properly work (grub has issue, I have to manually tell grub every time where the root, kernel and initrd is)
<candyban> It says it has ssh, but it immediately 'closes connection'
<candyban> and I had to click around for ages to get the **** dhcp to provision a machine. (sorry venting here)
<candyban> 'worlds best bare metal provisioning tool is quite a stretch imho. I have setup my own pxe systems quicker and easier than this (at least I knew what was going on)
<candyban> question: am I doing something wrong or do other people have similar experiences?
<kklimonda> you are probably doing something wrong
<kklimonda> MAAS has its warts, and lacks documentation, but it's not a POS
<ybaumy> kklimonda: i have issues now too. havent changed the setup but now the commissioning fails at boot time with mbr magic error
<iggy> candyban: I didn't have any problems
<Budgie^Smore> is there a cli way to determine when the first boot image is synced?
<pmatulis> kklimonda, what specifically is missing in the documentation?
<DesktopMan> <candyban> It says it has ssh, but it immediately 'closes connection' mine failed to provision and had the same ssh response. Turns out I had set the wrong ip for the region controller. I ran dpkg-reconfigure maas-region-controller and set it to the static IP used on the interface on the network used for PXE booting and it was fine afterwards
#maas 2018-02-19
<nrdmn_> hello
<aki> hi
<aki> quick question, I can't seem to find a definitive answer myself, does maas support ipxe?
<roaksoax> aki: as in, MAAS send ipxe config? no we dont
<roaksoax> not yet at least
<roaksoax> there's WIP but its been contributed
<aki> ok
<aki> thanks :)
<xygnal> roaksoax:  getting back in gear to test bare metat region controller for speed/memory leak.  do we need a replicate of our prod database or is fake generaeting 500 nodes sufficient?
<xygnal> roaksoax: if prod data is needed, interested in  your definition of how to safely prevent the test region controller from reaching the existing rack controllers.
<roaksoax> xygnal: US holiday today for us and i'm on my way out. Let's chat tomorrow
<xygnal> funny I am in the US and am required to work today =p
<roaksoax> xygnal: yeah not all companies observe federal holidays unfortunately
#maas 2018-02-20
<mup> Bug #1750540 opened: [2.3, UI] Filters break when navigating among Machine, device, controller tabs <ui> <MAAS:New> <https://launchpad.net/bugs/1750540>
<mup> Bug #1750604 opened: MAAS cli incorrect "Success" message  <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1750604>
<mup> Bug #1750622 opened: PXE boot on HP DL380 Gen9 is forced into a one time Legacy Boot Mode <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1750622>
<xygnal> can I have one untagged vlan and forwards multiple subnets?  or do i need one untagged vlan per subnet?
<xygnal> its all untagged with relay
<xygnal> roaksoax: ping
<roaksoax> xygnal: pong
<xygnal> roaksoax: 1.  I uploaded json dumps from websocket calls weeks ago, did you examine them?  no replies in bug report.         2. when we test bare metal, do we need to use our prod database data,  or would creating 500 fake nodes in CLI be sufficient?
<roaksoax> xygnal: for 1. unfortunately at the moment we dont have the cycles to investigate more your use case. For the priority to be bumped, i would need to have a support ticket
<roaksoax> xygnal: as for 2. doing 500 fake nodes
<roaksoax> would be a good test
<roaksoax> but those fake nodes would need to be commissioned
<roaksoax> and have testing results
<roaksoax> xygnal: the disadvantage to that, is that there's noone really doing power checking
<roaksoax> which could also be a reason why it's overloaded
<roaksoax> xygnal: also, I did  quick quest to see if I could reproduce your issue in different circumstances
<roaksoax> xygnal: 1. created a vm with 1 CPU + 2GB ram
<roaksoax> 2. added 100 real machines to MAAS
<roaksoax> 3. MAAS commissioned/deployed all of those machines
<roaksoax> it eventually run out of memory, which prevented the rack from being able to power manage the machnes
<roaksoax> but the UI was fully functional
<catbus> bladernr: <3
#maas 2018-02-21
<mup> Bug #1750688 opened: Disable Intel firmware embedded LLDP agent before collecting LLDP data <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1750688>
<mup> Bug #1750689 opened: [2.4] MAAS doesn't set the right DNS server when rackd.conf:maas_url is localhost <MAAS:Triaged> <https://launchpad.net/bugs/1750689>
<mup> Bug #1750714 opened: [2.4] PXE boot unconditionally updates interface VLAN <MAAS:Triaged> <https://launchpad.net/bugs/1750714>
<mup> Bug #1750862 opened: stress-ng-cpu short runs forever on Huawei Server <MAAS:Incomplete> <https://launchpad.net/bugs/1750862>
<mup> Bug #1750732 opened: grub package will change the boot order for MaaS deployed system <amd64> <apport-bug> <package-from-proposed> <uec-images> <xenial> <curtin (Ubuntu):New> <grub2 (Ubuntu):New> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1750732>
<mup> Bug #1750732 changed: grub package will change the boot order for MaaS deployed system <amd64> <apport-bug> <package-from-proposed> <uec-images> <xenial> <curtin (Ubuntu):New> <grub2 (Ubuntu):New> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1750732>
<mup> Bug #1750732 opened: grub package will change the boot order for MaaS deployed system <amd64> <apport-bug> <package-from-proposed> <uec-images> <xenial> <curtin (Ubuntu):New> <grub2 (Ubuntu):New> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1750732>
<mup> Bug #1750884 opened: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic <cloud-init:New> <MAAS:New> <https://launchpad.net/bugs/1750884>
<mup> Bug #1750884 changed: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic <cloud-init:New> <MAAS:Invalid> <nplan (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1750884>
<mup> Bug #1750891 opened: pod commission failed with "Ephemeral operating system ubuntu xenial is unavailable" <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Incomplete> <https://launchpad.net/bugs/1750891>
<mup> Bug #1750891 changed: pod commission failed with "Ephemeral operating system ubuntu xenial is unavailable" <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Incomplete> <https://launchpad.net/bugs/1750891>
<mup> Bug #1750891 opened: pod commission failed with "Ephemeral operating system ubuntu xenial is unavailable" <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:Incomplete> <https://launchpad.net/bugs/1750891>
<mup> Bug #1750914 opened: Changing hostname after deployment breaks maas install <MAAS:New> <https://launchpad.net/bugs/1750914>
<mup> Bug #1750923 opened: Can't edit interfaces on node in 'New' state <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1750923>
<catbus> roaksoax: Hi, wanted to check if adding interfaces on KVM Pod node is supported. I manually created two bridges on the KVM host and I was able to add the second interface to the VM via the MAAS web UI. The second interface is defined in the cloud-init.cfg on the VM, but only 1 interface is shown for the VM (virsh domiflist <domain>).
#maas 2018-02-22
<arun__> HELP
<arun__> I am trying to setup maas
<arun__> and adding one machine node
<arun__> but unable to commision the same
<JJ__> Trying to troubleshoot a problem with my maas setup relating to the public interface
<JJ__> My private interface is managed by MAAS along with DHCP and it seems to work fine, I can run conjure-up and it tries to bootstrap a juju node
<JJ__> however it gets stuck at running machine configuration scripts
<JJ__> I can ping google.com from the maas server on the public interface, I can't ping google.com from the juju node after ssh in
<roaksoax> Calvin`: not supported today unfortuantely
<roaksoax> Calvin`: err sorry
<roaksoax> arun__: that sound slike the machine cannot access the maas metadata. Make sure /etc/maas/rackd.conf points to itself in an IP that the machine can communicate to
<roaksoax> JJ__: so either you setup NAT'ing
<roaksoax> JJ__: or you tell juju to use MAAS as a proxy
<JJ__> hmmm... currently have 2 subnets in maas
<JJ__> one is private with dhcp managed by maas
<JJ__> other is public with dns and dhcp provided by switch downstream
<mup> Bug #1750884 opened: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution <cloud-init:New> <MAAS:Triaged> <nplan (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1750884>
<roaksoax> JJ__: right, but MAAS can install things from the archive because they use the apt proxy, aka MAAS
<roaksoax> JJ__: the system itself cannot reach the internet because it doens't have a global proxy configured
<roaksoax> JJ__: which is why either you enable NAT'ing, or tell the services you deploy with juju to use the proxy
<JJ__> for maas dashboard under settings I have proxy set for MAAS built-in
<JJ__> so you can enable NAT'ing through MAAS?
<roaksoax> JJ__: yes, that's APT proxy
<roaksoax> JJ__: that's not  a "system" proxy
<roaksoax> JJ__: https://askubuntu.com/questions/852154/juju-2-0-proxy-for-bootstrap/852931
<JJ__> Ok, not that familiar with conjure-up open stack kvm install.  How do you tell the services deployed with juju to use the maas proxy?
<roaksoax> JJ__: so you can do two things. IF you want machines to have access to the internet regardless of wether juju deployed them
<roaksoax> JJ__: you need to enable NAT
<roaksoax> how would you do that? If MAAS is your gateway, you need iptables rules to forward traffic
<roaksoax> from your public net, to hte internal net
<roaksoax> if you dont want to do that, you can tell juju to use a proxy. And that proxy would be MAAS
<JJ__> Like this? https://askubuntu.com/questions/590449/maas-network-and-nat
<roaksoax> JJ__: yeah similar
<roaksoax> JJ__: personally, I always use NAT
<roaksoax> but i jsut run a test environment
<JJ__> roaksoax__: in reading both links about proxying and NAT, it seems they apply to a situation where the maas server is the only server with 2 nic's
<JJ__> roaksoax__: in my situation all nodes have 2 nic's with one for the private subnet managed by MAAS and the other for public network.
<catbus> roaksoax: Hi, wondering if you got my question yesterday and whether I missed the reply because I was on and off the chat.
<catbus> roaksoax: I think I found the answer, https://github.com/maas/maas/blob/master/src/provisioningserver/drivers/pod/virsh.py only attach one interface. Even though I have two defined for the VM node (cloud-init is configured accordingly) but only one interface is created along with the VM creation.
<JJ__> anyone know why maas wouldn't pass the gateway or allow the gateway to be passed from an external DHCP server?
<roaksoax> catbus: we dont use the templates from kvm/libvirt, we use our own
<JJ__> after commissioning I have tried auto assign, DHCP & Static for the public interface and none seem to allow the gateway to be passed to the node in its cloud config file
<JJ__> maas correctly passes the gateway for the private managed interface
<JJ__> if a gateway is passed it appears that NAT works, without a gateway - no NAT
<catbus> roaksoax: I don't follow. What do you mean we don't use the templates from kvm/libvirt?
<roaksoax> catbus: we dont create vm's based on what you have manually defined in libvirt
<roaksoax> e.g. if you have multiple networks in libvirt
<roaksoax> we dont use that
<catbus> roaksoax: yeah, I have to manually attach the second nic to the VM to use the second bridge I create on the kvm host.
<catbus> thanks for the confirmation.
<JJ__> roaksoax__: do you know if there is an issue with maas passing gateways ending in .254 instead of .1
<roaksoax> JJ__: no known issues, shouldn't really be an issue if maas is the gateway or is not the gateway
<roaksoax> JJ__: when you configure DHCP you should tell it where the gateway is
<mup> Bug #1711203 opened: Deployments fail when Secure Boot enabled <blocks-hwcert-server> <id-5a28802797729aedf99dcd37> <curtin:Invalid> <dellserver:New> <MAAS:Triaged
<mup> by andreserl> <MAAS 2.3:Triaged by andreserl> <maas-images:Fix Released by ltrager> <grub2 (Ubuntu):In Progress by cyphermox> <https://launchpad.net/bugs/1711203>
<JJ__> roaksoax__:  I have the gateway configured in maas and in an external dhcp for the public internet interface, it is unmanaged and although I can get maas to assign an ip address from a  range, the gateway doesn't pass through.
<JJ__> I tested the external dhcp and it does pass the gateway
<JJ__> roaksoax__: is it possible to deploy a node with 2 fabric's, one on a private subnet with dhcp managed by maas and one on a public subnet with dhcp provided externally
<JJ__> roaksoax__: according to the maas docs unless I am reading it wrong, it appears for the public subnet where dhcp is not managed by maas it doesn't pass the gateway to the node during deployment.
<roaksoax> JJ__: yes it is possible
<roaksoax> JJ__: you just have to set the interface to DHCP
<JJ__> roaksoax__: when I set the public interface to dhcp then maas doesn't pass the gateway in the cloud config file and I haven't found a persistent way to modify the interface on the node to add it in.
#maas 2018-02-23
<arun__> #roaksoax will you able to share one sample config file for rackd.conf, it will be very helpfull
<tosaraja> Is there a reason why power_parameters_power_address can't be read from the CLI? Or is it just me now knowing how to read it?
<mup> Bug #1751300 opened: [2.4] No way to enable dynamic worker creation <MAAS:Triaged> <https://launchpad.net/bugs/1751300>
<roaksoax> tosaraja: maas admin machine power-parameters <machine_system_id>
<utriple> hi I'm having an issue where maas doesn't pick up any storage device in my super micro box
<utriple> https://drive.google.com/file/d/1zYRzNHj6m5sw8i0TOmXViSEaYKg44nSV/view
<utriple> I had this issue a while ago and posted in here ~1 month back
<utriple> this the testing hardware stage of doing a commision a server
<utriple> let me find the command it was failing on
<xygnal> roaksoax: in bug report you gave example command to generate 500 fake nodes, but it seems not all of the data needed to try it ourselves is there.     you also mention you do this after running 'make run', which is perhaps what we are missing.
<xygnal> 1744765, actually it was mike :)
<xygnal> mpontillo:
<xygnal> can you help me to fill out the missing peice to do that?  a co-worker is trying to test that out.
<xygnal> comment #7
<mpontillo> xygnal: that comment was probably specific to the MAAS dev env; your coworker might want to read through https://github.com/maas/maas/blob/master/HACKING.rst
<utriple> my bug report is on that google drive link if anyone is curious
<xygnal> mpontillo: ty sir :)
<mpontillo> xygnal: sure. keep in mind that you will need to develop on Xenial in order to work with MAAS 2.3 sources, and on Bionic to work with MAAS 2.4 sources
<mpontillo> xygnal: so if you are working on 2.3 code on Xenial, that's fine, just remember to check out the 2.3 branch
<xygnal> will we need to upgrade to bionic to be able to use 2.4 prod?
<roaksoax> xygnal: yes
<roaksoax> 2.4 wont be backported to xenial
<xygnal> will that also be the migration to snaps? or is that not here yet
<roaksoax> xygnal: we will continue to produce debs, at least for 2.4
<roaksoax> xygnal: and we are evaluating making 2.4 available in xenial only as a snap
<roaksoax> so lts users dont have to upgrade the underlying os
<roaksoax> as snaps give that flexibility
<utriple> nvm I figured it out
#maas 2018-02-24
<mup> Bug #1750923 changed: Can't edit interfaces on node in 'New' state <cdo-qa> <MAAS:Fix Released> <https://launchpad.net/bugs/1750923>
<mup> Bug #1750923 opened: Can't edit interfaces on node in 'New' state <cdo-qa> <MAAS:Fix Released> <https://launchpad.net/bugs/1750923>
<mup> Bug #1750923 changed: Can't edit interfaces on node in 'New' state <cdo-qa> <MAAS:Fix Released> <https://launchpad.net/bugs/1750923>
#maas 2018-02-25
<mup> Bug #1751540 opened: Sorting "Last Seen" on "Dashboard" sorts by string, not by timestamp <dashboard> <sorting> <ui> <MAAS:New> <https://launchpad.net/bugs/1751540>
<tosaraja> roaksoax: thanks! was going for the data provided by 'machines read'.
<terrycain> Hey guys, I really like the libvirt chassis/power management part. If I wanted the same sort of functionality when using xenserver where abouts would you recommend starting? I know the xen api pretty well so i think its just a case of slotting it in somewhere
#maas 2020-02-17
<mup> Bug #1815843 changed: pod kvm fails to boot for install, boot-kernel transfer size is wrong <cdo-qa> <MAAS:Expired> <https://launchpad.net/bugs/1815843>
<mup> Bug #1863597 opened: rack controller fails to register because of failure updating interfaces <MAAS:Triaged> <https://launchpad.net/bugs/1863597>
<mup> Bug #1863597 changed: rack controller fails to register because of failure updating interfaces <MAAS:Triaged> <https://launchpad.net/bugs/1863597>
<mup> Bug #1863597 opened: rack controller fails to register because of failure updating interfaces <MAAS:Triaged> <https://launchpad.net/bugs/1863597>
#maas 2020-02-18
<mup> Bug #1863723 opened: CPU/Mem overcommit settings look disabled when editing a Pod <ui> <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1863723>
<jbl> I have a problem with passing custom user-data: "maas deploy user_data=$(base64 -w0 example.ign)" works fine but "maas deploy user_data@=example.ign" leaves the user data being empty
<jbl> any pointers what I'm doing wrong?
<mup> Bug #1863791 opened: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1863791>
<mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1863791>
<mup> Bug #1863791 opened: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1863791>
<mup> Bug #1863791 changed: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1863791>
<mup> Bug #1863791 opened: apt-install of maas-rack-controller fails trying to connect to maas-internal hostname <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1863791>
#maas 2020-02-19
<mup> Bug #1847011 changed: Return osystems and distro_series requiring keys from the general.osinfo websocket API <MAAS:Invalid> <https://launchpad.net/bugs/1847011>
<mup> Bug #1847011 opened: Return osystems and distro_series requiring keys from the general.osinfo websocket API <MAAS:Invalid> <https://launchpad.net/bugs/1847011>
<mup> Bug #1847011 changed: Return osystems and distro_series requiring keys from the general.osinfo websocket API <MAAS:Invalid> <https://launchpad.net/bugs/1847011>
<mup> Bug #1863905 opened: [websocket-api] No method to get a full list of supported chassis types <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863905>
<mup> Bug #1863906 opened: No websocket method for adding chassis  <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863906>
<mup> Bug #1863905 changed: [websocket-api] No method to get a full list of supported chassis types <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863905>
<mup> Bug #1863906 changed: [websocket-api] No websocket method for adding chassis <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863906>
<mup> Bug #1863905 opened: No method to get a full list of supported chassis types <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863905>
<mup> Bug #1863906 opened: No websocket method for adding chassis <websocket-api> <MAAS:New> <https://launchpad.net/bugs/1863906>
<mup> Bug #1863918 opened: Feature Request: Allow user specified vendor-data to be applied to all machines <MAAS:Incomplete> <https://launchpad.net/bugs/1863918>
#maas 2020-02-20
<mup> Bug #1856751 opened: API create_bond with multiple parents in array not accepted <cpe-onsite> <field-high> <MAAS:New> <https://launchpad.net/bugs/1856751>
<mup> Bug # changed: 1067332, 1246479, 1346279, 1551730, 1698181, 1843855
<mup> Bug #1864097 opened: Default instructions to add rack controller retrieve stale version <ui> <MAAS:New> <https://launchpad.net/bugs/1864097>
#maas 2020-02-21
<mup> Bug #1864123 opened: traceback when creating user using existing email <MAAS:New> <https://launchpad.net/bugs/1864123>
<mup> Bug #1864210 opened: no way to crash-cart the ephemeral - maas should pass ssh keys to ephemeral on boot <MAAS:New> <https://launchpad.net/bugs/1864210>
<mup> Bug #1864222 opened: attempting to update network interfaces in NEW state can silently break config <MAAS:New> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864222 changed: attempting to update network interfaces in NEW state can silently break config <MAAS:New> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864222 opened: attempting to update network interfaces in NEW state can silently break config <MAAS:New> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864222 changed: attempting to update network interfaces in NEW state can silently break config <MAAS:New> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864222 opened: attempting to update network interfaces in NEW state can silently break config <MAAS:New> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864222 changed: attempting to update network interfaces in NEW state can silently break config <MAAS:Invalid> <https://launchpad.net/bugs/1864222>
<mup> Bug #1864241 opened: Cannot edit physical interface in gui <MAAS:New> <https://launchpad.net/bugs/1864241>
#maas 2020-02-22
<noogie> are there any docs on upgrading from ppa installed maas 2.6 to snap 2.7?
#maas 2020-02-23
<mup> Bug #1864385 opened: MAAS Backup Instructions Contain a Typo <MAAS:New> <https://launchpad.net/bugs/1864385>
