#maas 2012-11-19
<jam> mgz: now we just hear ourselves echo on about a 1s delay
<evilnickveitch> question: is there any reason for the end user to use the 'maas' command for anything other than "createsuperuser" and "changepassword"?
<rvba> evilnickveitch: these are the main commands that a user should use.  Maybe it's worth mentioning a third one: 'shell' used to get a python prompt with the right (django) environment setup.  That is mainly for debugging purposes.
<evilnickveitch> rvba: thanks!
<rvba> np
<rbasak> allenap: re: maas-import-ephemerals, I had a precise SRU in mind, hence changing the existing script as minimally as possible. Not sure of the current SRU plans. If the whole thing were rewritten, would this affect the SRU? Would the refactoring be SRUed?
<allenap> rbasak: We're aiming for a big SRU, so that Precise's version is close to trunk (there will be two features missing, I think that's it).
<allenap> rbasak: The problem with maas-import-ephemerals is that there are no tests, so it's hard to refactor.
<rvba> allenap: thanks for the reviews.  You're so quick I don't even have to ask. :)
<rbasak> allenap: I understand. The complexity of mass-import-* is such that if I were starting from scratch I would write it in python, with tests.
<allenap> rvba: No worries.
<rbasak> I think it's gone beyond the point where shell is appropriate. smoser might disagree though!
<rbasak> But I feel that I'm facing a problem now though. I seem to have a choice between taking on the refactoring myself, or not getting multi-subarch ARM support into precise.
<smoser> i dont really care, but i generally disagree with any sort of "cannot be tested BS".
<smoser> test the freaking thing.
<smoser> dont pretend you do by running 'make test' that mocks 90% of it.
<allenap> rbasak: I think >1 line of shell is beyond appropriate, but some might say that's extreme.
<smoser> but, sure, rewrite if you feel like it.
<allenap> smoser: Do you mean automated testing, or manual?
<smoser> well, when you make changes you should do test of your changes. period.
<smoser> not writing unit tests that pretend to test.
<rbasak> allenap: I think you're too extreme there, but I think we can both agree that the appropriate language for the current functionality of maas-import-* is python.
<allenap> smoser: Does that mean we need to test every script every time we make a change? Because I'm not going to do that manually.
<rbasak> (though I would be fine if smoser disagreed with that - I'm only slightly on the side of python on this one)
<smoser> there shoudl be some sort of ci testing in place. but, yes, if you change things, you should test them.
<smoser> that really should not be questionable.
<smoser> there should also be some sort of easily runnable "setup and test". we're lacking in that department.
<rbasak> The nature of maas is that unit tests can't do everything. I'm not sure they're even appropriate in some cases. That's why we should have integration tests. And I'm starting to think that maas-import-* should have all of the functionality that we need to test covered by our integration tests anyway, and matsubara is already working on this. So do we really need any other tests for it?
<smoser> so people take short cuts. and do not test their code in reality.
<allenap> smoser: Yeah, so we have unit tests in lp:maas, and /some/ integration testing, though it's a ad-hoc. matsubara (and rvba I think) have been working on the acceptance testing of the package, so I guess maas-import-* will be covered by that eventually.
<smoser> right. we need to get to the point where someone can reasonably push 'go' with input of a branch. and that would build package, laucnh instance (or instances) install package, launch vms....
<smoser> that would at least test the expected user path
<matsubara> we're at that point
<matsubara> with the CI tests in jenkins
<rvba> That's what the integration tests do.
<matsubara> and yes, the CI tests did catch some bugs in maas-import-pxe-files
<smoser> matsubara, can allennap  run that?
<smoser> and does he need access to hardware to do so?
<rvba> No, he just needs an account on the jenkins instance.
<allenap> smoser: Yes, agreed. But we should still have unit tests for small piece of functionality, because detecting bugs late - i.e. in the integration tests - is much more expensive.
<matsubara> smoser, yes and no (although he does have access to the lab)
<rbasak> matsubara: are we really there yet? For example, I've proposed https://code.launchpad.net/~racb/maas/multi-soc-ephemerals/+merge/134715 which changes maas-import-pxe-files which is where our discussion started. Can you give me a green light that this doesn't break anything, how much of your time would that take, and how confident would you be about the results?
<matsubara> but yes, I agree that if maas-import-pxe-files tests could be part of the maas test suite, that would be nice
<smoser> matsubara, we need to remove the necessity of "lab access" also.
<matsubara> smoser, lab access is useful to debug when the CI tests fail
<smoser> matsubara, clearly, yes.
<smoser> it can all run (minus ipmi) inside an instance[s] and a subset of that can run on a local system.
<smoser> ie, "all in one" can run on a single system. or a single vm with nested virt.
<allenap> Compared to setting up a lab, both in terms of equipment and time, writing unit tests is insanely cheap, finds bugs and helps reduce regressions.
<smoser> i didn't say that unit tests are not useful.
<smoser> i said they're not complete. and you should test code you write.
<matsubara> rbasak, the arm nodes are not working at the moment. I had an issue updating the chassis firmware and will talk to Massimo today
<smoser> and not doing so is unacceptable.
<rbasak> matsubara: ok, but in general?
<smoser> i'll end my rant.
<matsubara> rbasak, apart from that the CI infrastructure should be working
<rbasak> What if the lab tested merge proposals or just maas branches on demand and sent us the results?
<rbasak> matsubara: and can it do what I mentioned above?
<smoser> rbasak, right.
<smoser> and then, we want to detach that from the lab.
<matsubara> rbasak, it does that for the unit tests test suite, but not for the CI
<matsubara> currently CI tests takes around 30 mins including juju tests
<matsubara> so blocking landings on CI, would make development speed a lot slower
<rbasak> '
<rbasak> I'm happy with that for maas-import-pxe-files changes. We don't change it that often. A day would be fine
<matsubara> cool
<allenap> smoser: I don't really know what you're ranting against. Diogo has been doing QA since the beginning, and is codifying this in the acceptance test suite. We haven't been missing the part that you're worried about.
<rbasak> So do we have the facility to automatically test that MP now?
<allenap> rbasak: I /think/ we need to land it before it'll be visible to the acceptance suite. Is that correct, matsubara?
<smoser> allenap, assuming QA will catch stuff is rude.
<matsubara> yes allenap and rbasak
<smoser> ie, assuming the first time it will run in an actual environment rather than unit test is the failure.
<rbasak> allenap: let's say that we did have the facility to pass acceptance tests without landing it. I do accept that we want to refactor maas-import-* eventually. Would you still feel the same about not landing this MP without refactoring though?
<smoser> wait. thats not a sentance.
<smoser> assuming QA / integration testing will be the first time something runs because the person who changed it couldn't be  bothered to run it. is rude to anyone else who is going to try to use the product.
<smoser> rbasak, what is the MP ?
<smoser> link ?
<rbasak> smoser: https://code.launchpad.net/~racb/maas/multi-soc-ephemerals/+merge/134715
<rbasak> I've tested this and can't find that it breaks anything. But I can't be completely confident about this without knowing that the acceptance tests also pass, and ideally I'd like to know that before merging it into trunk.
<smoser> rbasak, you need to use more quotes.
<smoser> cp $src/subarch/$subarch/initrd.gz needs to be cp "$src/subarch/$subarch/initrd.gz"
<smoser> as src can have space and yo ufail.
<smoser> i dont do things like that just for fun.
<rbasak> smoser: that's fine
<allenap> smoser: I don't see that it's rude. For many situations we don't have the facility to spin up a representative MAAS environment. The QA team - Diogo - does, and has the expertise and focus to do that job better than I can.
<smoser> you *do* have the facility.
<smoser> allenap, do you ahve a canonistack account?
<smoser> if not, you should.
<allenap> smoser: Yes, but that's not a representative environment.
<smoser> allenap, it is for the test in question. (and actually just about everything we do other than ipmi)
<rbasak> Very little of bits that matter for ARM though
<smoser> ?
<smoser> there are some arm specific paths. thats true. but the majority of this is not arch specific.
<allenap> smoser: How does canonistack help us test DHCP and PXE better than a unit test?
<rbasak> allenap: it would test that stuff actually works, rather than what a unit test tests
<Daviey> you can PXE install using canonistack.
<rbasak> While I was working on ARM support, I found stuff that was not ARM specific that was simply broken but all unit tests passed
<rbasak> That was happening every other day or so
<rbasak> It appeared that I was the only one trying trunk on real hardware all the way through at the time
<allenap> Daviey: I didn't know that. How do we get a booting node to select our tftp server, in order that we can control the PXE boot?
<rbasak> (the situation is a lot better now thanks to the automation that matsubara has done)
<rbasak> But it demonstrates well that the unit tests are not sufficient, especially for the system-level parts like dhcp, pxe, ipmi, etc.
<allenap> rbasak: I agree, when things need hardware there's usually little option but to go to hardware.
<rbasak> dhcp and pxe don't need hardware for non-IPMI. KVM will do
<Daviey> allenap: pxe-tftp tool :)
<Daviey> pxe-kexec, rather
<rbasak> We should definitely also be testing on real hardware, but velocity will be better if there are integration tests that can run in a virtual environment (or if we can submit stuff to real hardware quickly and easily, including debugging)
<smoser> rbasak, i commented.
<allenap> Daviey: That's pretty cool. Doesn't test our DHCP integration, but it's neat, granted.
<smoser> you dont need pxe-kexec.
<smoser> you actually boot a vm
<smoser> and let the bios pxe boot
<smoser> just like a real machine.
<smoser> rbasak, i updated mp.
<rbasak> thanks smoser. I can make those changes - the bigger question is if this is sufficient or really needs an entire refactor before this can go in
<smoser> rbasak, i dont have a problem with it as it is. and my personal feeling would be actually testing it would result in less regression than refactor/re-write in python.
<smoser> (at least in the short term)
<allenap> rbasak: I'm not arguing against integration/acceptance testing; I'm arguing that we need unit tests too. Refactoring code without unit tests is tricky and expensive (the latter because of the long iteration time).
<smoser> allenap, i will agree with you on that.
<rbasak> allenap: that's fine. If we refactored maas-import-* then we could have unit tests, and I'm fine with that. But I'm not sure that we want to block this until it is refactored. Perhaps even more so with an SRU planned.
<rbasak> allenap: and who is going to refactor it?
<allenap> smoser: My arguments against shell are twofold: it's incredibly easy to hide serious bugs in shell (e.g. "use more quotes"), and that it's hard to unit test (at least as maas-import-* are currently written).
<allenap> rbasak: You may be right that we don't want to block on this, and I don't know who's going to refactor it, but these are the same arguments that keep coming up. Every time we grow those scripts we are making the rectification job harder. I want to put the brakes on.
<rbasak> Understood. My work on apt is in the same situation.
<rbasak> There are a couple of other factors there though. Not sure how much they apply though
<rbasak> For an SRU, I wouldn't normally want to do a refactor. Minimal change would almost always be better.
<rbasak> Here though, maas is a bit special with its SRU
<rbasak> But in the case of this particular change, it's because I had to take a shortcut and not put multi-subarch support in ephemeral images before 12.10 release. It's a pretty bad deficiency in ARM support, and I had assumed that this would be fine to SRU later, in time for new ARM hardware to arrive
<rbasak> It's the last piece to do before I'm happy with the ARM support in MAAS, and I really hoped to have it done by now. Which is why I'm reluctant to embark on refactoring the entire chunk before I can complete it, especially because that isn't even an ARM issue
<smoser> rbasak, i personally think your change here is the right path. i do see allenap's point about adding more stuff to something that wants a refactor, but i think for now this is the safest path.
<rnbrady> Hi guys
<rnbrady> Just been playing with maas over last week and loving it.
<rnbrady> But still haven't got my first server up.
<rnbrady> So far I have the maas server running, enlisting nodes, and serving some pxeboot.
<rnbrady> But getting lots of weirdness in the commissioning process and could use a few tips if anyone about.
<roaksoax> rvba: do you recall when was the apprmor stuff uploaded... or in what package version?
<roaksoax> smoser: ^^ do you?
<roaksoax> rvba: the fix for it is already in -proposed and needs verification: 1049177
<roaksoax> rvba: the fix for it is already in -proposed and needs verification: bug #1049177
<ubot5> Launchpad bug 1049177 in maas (Ubuntu Precise) "isc-dhcp-server apparmor profile should have include ".d" " [Undecided,New] https://launchpad.net/bugs/1049177
<roaksoax> rvba: could you please get that tested?
<rvba> roaksoax: thanks.  Sure I'll test that.  I need to bugger off now but I'll do it tomorrow.
<roaksoax> rvba: cool thanks
<smoser> roaksoax, did you get what you wanted?
<roaksoax> smoser: yes, thanks!
<roaksoax> matsubara-brb: how do you configure maas dhcp server?
<roaksoax> and enable it?
<matsubara> maas-cli maas node-groups list | grep uuid
<matsubara> maas-cli maas node-group-interface update uuid eth1 ip=192.168.21.5 interface=eth1 management=2 subnet_mask=255.255.255.0 broadcast_ip=192.168.21.255 router_ip=192.168.21.1 ip_range_low=192.168.21.10 ip_range_high=192.168.21.30
<matsubara> roaksoax, ^
<roaksoax> matsubara: cool thanks
<matsubara> np
<rnbrady> Newbie question. For maas-cli, is the profile name arbitrary?
<rnbrady> I can do maas-cli login maas or maas-cli login iamoneleggedman, and both work.
<matsubara> yes rnbrady
<rnbrady> Tks. So it's just an alias for an API from what I have since discovered.
<rnbrady> Nifty! Just issued my first maas-cli maas start xxx
<rnbrady> The thrill of hearing fans whirring spontaneously on the other side of the room and the press of a key
<rnbrady> s/and/at/
<rnbrady> Currently trying to work out how to do a named deployment, as I am only getting the option to queue for allocation.
<rnbrady> Ok, which one of you sadists commented out NODE_AFTER_COMMISSIONING_ACTION.DEPLOY_12_04 from NODE_AFTER_COMMISSIONING_ACTION_CHOICES?
<rnbrady> Wahoo! It's alive! Named deployment 12.04!
#maas 2012-11-20
<bigjools> roaksoax: how close to the quantal SRU are we?
<roaksoax> bigjools: i uploaded a new verrsion today for quantaul, haven't uploaded a precise one yet
<roaksoax> bigjools: but there's 1 more packaging change i need to make
<roaksoax> and we should be good
<bigjools> roaksoax: \o/
<bigjools> we're testing the precise package in earnest
<bigjools> a few bugs, but getting there
<bigjools> I am upload a new one ATM
<bigjools> uploading*
<roaksoax> bigjools: right, so the most tedious thing is filing SRU bugs
<bigjools> roaksoax: yeah :(
<smoser> bigjools, awake ?
<bigjools> smoser: of course
<smoser> https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs
<smoser> i'm trying to do:
<smoser>  {{node.architecture|default:"nothing"}}
<smoser> in a preseed
<smoser> and it says
<bigjools> we don't use django templates in preseeds
<bigjools> http://pythonpaste.org/tempita/
<smoser> gah
<bigjools> :)
<smoser> that would be why the trace said 'tempita' :)
<bigjools> haha
<smoser> bigjools, so... 2 things iw ant to do.
<smoser> it seems that node.distro_release might be None when evaluated (which generally seems wrong to me)
<smoser> and second i want the architecture portion of 'node.architecture'
<smoser> (which is 'amd64/generic')
<smoser> suggestions on how to do that?
<bigjools> I don't know why release would be None
<bigjools> for arch, you can include a python block
<bigjools> so {{py: .... }}
<bigjools> you can split on the /
<smoser> not None, but renders to empty string
<bigjools> hmm
<bigjools> can you see if it's set in the DB?
<smoser> bigjools, well, from http://localhost:8080/MAAS/nodes/node-628a5c14-24db-11e2-84ac-d4ae527ac125/preseedview/
<smoser> i'm using {{node.distro_series}}
<smoser> how easiest to check the db ?
<bigjools> sudo maas shell
<bigjools> from maasserver.models import Node
<smoser> thats for an un-allocated node
<smoser> one that is "ready"
<smoser> for one that is deployed, it does have one
<bigjools> oh ok, then that makes sense
<bigjools> if it's not deployed it doesn't have any OS
<smoser> it should have the default.
<bigjools> why?
<bigjools> what are you trying to do?
<smoser> i'm trying to use it.
<smoser> and the rendered view of the preseed is broken
<smoser> because it doesn't have a value.
<smoser> but there is a default value
<smoser> so it should have that
<bigjools> I don't think it's broken based on the intended usage
<bigjools> what do you need the preseed for, before it's deployed?
<smoser> if i dont need it, then why does it show it to me?
<bigjools> that's not what I asked :)
<smoser> if it weren't nicely displayed in the UI, i'd have no argument.
<bigjools> the info presented is correct
<bigjools> you could argue that the distro series is not useful though - but it would also be incorrect if it showed the defaut and you then deployed a different series
<smoser> well that would clearly be wrong.
<smoser> but if it displayed the default, and then deployed the default (because i didn't specifically request something else) that would be right.
<smoser> but if i change it, then, well, i changed it, didnt i
<smoser> not a terribly large deal, but if this is something that is surfaced to users (which it generally ise) then it is confusing at best to have "" there. when there is (i think) a system wide default.
<bigjools> I think your expectations are different to mine here.  That's not to say you're wrong, just different.  It's an interesting problem.
<rvba> roaksoax: thanks for the backport of raphael js.  I've tested the package in -proposed.  It fixes the apparmor problem all right.
<roaksoax> rvba: awesome then! I can start taking care of filing SRU bugs then
<rvba> roaksoax: the package of python-django that Julian has put in the experimental ppa is also fine.
<roaksoax> rvba: alright, I need to review that and make sure we can SRU it
<roaksoax> rvba: i believe he put a patch which is upstream and not fixed in raring?
<rvba> roaksoax: I hope you'll succeed because we need it ;).  Well, technically, there is a last resort option but the SRU would be much better.
<rvba> roaksoax: he has backported a new utility method 'prefetch_related' that we need to optimise SQL queries.
<rvba> roaksoax: he has backported the fix for 16937.
<rvba> roaksoax: https://code.djangoproject.com/ticket/16937
<ubot5> Django bug 16937 in Database layer (models, ORM) "Prefetch related objects" [Normal,Closed]
<roaksoax> rvba: right, nt is that right but is that part of django in precise?
<roaksoax> err
<roaksoax> i mean in raring?
<rvba> It's part of Django 1.4 which is in Quantal
<roaksoax> rvba: oh ok, so it is easy to SRU then
<rvba> Cool
<hazmat> greetings maas devs
#maas 2012-11-21
<bigjools> roaksoax: I approved your packaging change
<bigjools> can I land it as-is?
<roaksoax> bigjools: cool thanks
<bigjools> roaksoax: actually
<bigjools> roaksoax: wait
<bigjools> I have got so many branches I am getting them mixed up
<roaksoax> bigjools: so I created a packaging.precise.sru which is what was in quantal at the time, plus your merges
<roaksoax> bigjools: or your change to the upstart job
<roaksoax> bigjools: i'll get that updated :)
<bigjools> we have not backported the celery import-pxe-files
<roaksoax> bigjools: ok, no harm since it was only a 1 line addition
<roaksoax> to the sudoers file for maas
<bigjools> roaksoax: no I mean your https://code.launchpad.net/~andreserl/maas/quantal_packaging_updates/+merge/135264
<bigjools> it was more than that, 167 lines of diff :)
<roaksoax> bigjools: the change for that is: debian/extras/99-maas-sudoers
<roaksoax> bigjools: the rest, is for maas-cluster-controller shipping maas-import-pxe-files and storing the images
<bigjools> roaksoax: none of it is needed
<bigjools> I think
<bigjools> grar, let me check again
<roaksoax> bigjools: hold on, isn't bug #1068843 the one one which the cluster controller has to have the images?
<ubot5> Launchpad bug 1068843 in maas (Ubuntu Raring) "maas-cluster-controller doesn't have images for provisioning" [High,Triaged] https://launchpad.net/bugs/1068843
<roaksoax> bigjools: so that bug,which i see was backported to the stabilkization branch is where the images are no longer on the region controller and are on the cluster controller
<bigjools> roaksoax: right right
<bigjools> I am getting two changes mixed up
<roaksoax> bigjools: the thing for celery to work, was simply adding permission for the maas user to run maas-import-pxe-files
<roaksoax> bigjools: which is a 1 line change
<bigjools> roaksoax: yup :)
<roaksoax> bigjools: ok, so now
<roaksoax> bigjools: i have updated it
<roaksoax> :)
<roaksoax> bigjools: now, I had to rebase the python-django package because a securoity fix landed in archives
<roaksoax> bigjools: and your changes needed to be applied on top of that package
<roaksoax> bigjools: now, It would be great if you could open a bug report for each of those patches
<bigjools> roaksoax: you already did it? I was about to do it
<bigjools> :)
<roaksoax> so i can reference the changelog and SRU the package
<bigjools> I will file
<bigjools> where is your precise packaging branch?  I made a bunch of changes just in the PPA
<bigjools> (for maas)
<roaksoax> bigjools: awesome, assign them to me and I'll take care of the rest
<bigjools> coolio
<roaksoax> bigjools: lp:~maas-maintainers/maas/packaging.precise.sru
<roaksoax> bigjools: this is the only change i made of top for the packaging: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging.precise.sru/revision/146
<roaksoax> in comparison to the quantal one
<roaksoax> bigjools: in terms on packaging I didn't see any other change
<bigjools> roaksoax: ok I have a *bunch* of changes, it might be best if I just blow your branch away and replace it with mine
 * bigjools diffs
<roaksoax> bigjools: sure, branch the quantal with the recent changes you just approved and put them on top
<roaksoax> bigjools: that way I can make sure what differs from quantal
<bigjools> I branched the old precise packaging and changed on top of that
<bigjools> since that is the branch that we really want to use, right?
<roaksoax> bigjools: uhmmm nope
<bigjools> whut?
<roaksoax> bigjools:  the quantal branch updates precise -> quantal right?
<roaksoax> bigjools: the quantal version is going to be the same as precise
<bigjools> the code is the same, the packaging is a fair bit different now
<roaksoax> bigjools: it shouldn't be
<bigjools> but I see why you're approaching it this way
<bigjools> let me diff them, hang on
<roaksoax> bigjools: note that when you backport, you use the same package as ubuntu+1, + any singularities that you need to do in that particula release
<roaksoax> bigjools: in our case, we are SRU'ing a whole release
<bigjools> ok
<roaksoax> so the packaging should be the same + changes for precise
<roaksoax> bigjools: cause the upgrade path is going to be the same
<bigjools> well for reference, here's the diff from my your sru packaging to my sru packaging http://pastebin.ubuntu.com/1373861/
<roaksoax> bigjools: yeah, too much complication :)
<roaksoax> s/too much complication/too complicated/
<bigjools> I have an equally big diff to the quantal branch
<bigjools> let's see what I can do
<roaksoax> bigjools: the one iuploaded in the PPA, only seemed to have the upstart changes as packaging changes
<bigjools> I have changelog and upstart
<roaksoax> bigjools: right, I merged your changelog entry for the upstart change
<roaksoax> bigjools: and i added all the biuglist we are closing
<roaksoax> bigjools: which you partially had
<roaksoax> bigjools: there should not be any more changes AFAIK
<bigjools> indeed
<roaksoax> bigjools: ok so I will rebase packaging.precise.sru with latest fixes
<bigjools> roaksoax: looks like your branch is up to date then
<bigjools> excellenbt
<bigjools> roaksoax: did you rebase the django package already?
<roaksoax> bigjools: yes
<bigjools> roaksoax: awesome
<roaksoax> :)
<roaksoax> bigjools: alright, I hope that tomorrow i can at least upload yui3, python-tx-tftp, and django
<bigjools> \o/
<bigjools> to quantal and precise?
<roaksoax> yui3, django to precise
<roaksoax> and python-tx-tftp to quantal, and once accepted to precise
<bigjools> nice!
 * bigjools files bugs
<bigjools> roaksoax: 1st one https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081388
<ubot5> Ubuntu bug 1081388 in python-django (Ubuntu) "Backport prefetch_related from 1.4" [Undecided,New]
<roaksoax> bigjools: could you also please explain what it does, or "fixes" maas problem
<bigjools> roaksoax: any better?
<bigjools> roaksoax: 2nd https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081391
<bigjools> one more to go
<ubot5> Ubuntu bug 1081391 in python-django (Ubuntu) "Backport GenericIPAddressfield from 1.4" [Undecided,New]
<bigjools> roaksoax: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1081392
<ubot5> Ubuntu bug 1081392 in python-django (Ubuntu) "Include upstream bug 15496" [Undecided,New]
<bigjools> I can attach patches for reference if you need
<roaksoax> bigjools: cool thanks
<roaksoax> bigjools: no not really
<bigjools> ok
<roaksoax> i'll take care of them tomorrow
<roaksoax> now, I'm off
<roaksoax> have a good day :)
<bigjools> roaksoax: excellent, thank you.  Have a good evening!
<AskUbuntu> Adding nodes to MAAS server | http://askubuntu.com/q/220049
<Nafallo> hi
<Nafallo> where in maas can I define my own preseeds? :-)
<Nafallo> I need to specify an http proxy for apt in my environment.
<bigjools> Nafallo: yes, /etc/maas/
<bigjools> edit existing one
<Nafallo> can't see one in there?
<Nafallo> I'm using Ubuntu 12.10 btw.
<Nafallo> so maas=0.1+bzr1269+dfsg-0ubuntu1
<bigjools> Nafallo: I have to dash, rvba should be able to point you to the right place
<bigjools> but 12.10 already points a proxy at the squid-deb-proxy on the region controller
 * bigjools outta here
<rvba> Nafallo: the preseeds are in /usr/share/maas/preseeds/
<rvba> Nafallo: like bigjools said, you'll see that /usr/share/maas/preseeds/generic already sets the proxy to be the squid-deb-proxy on the region controller
<Nafallo> hmm. I guess the alternative is to point squid-deb-proxy to use a proxy then? :-P
<Nafallo> cause my maas is on rfc1918 space, and I'm not planning to NAT it.
<rvba> Yeah, you can configure that proxy to use a parent proxy.
<Nafallo> I think that will be the best option then, cause currently the machines just time out :-)
<Nafallo> thanks. I'll test that :-)
<rvba> roaksoax: Hi Andres.  Quick question for you, what is the format of the generated /etc/maas/maas_cluster.conf file?  Right now we have only one value in there (MAAS_URL=http://10.98.0.90/MAAS).  Is that guaranteed that it will be key=value\nkey2=value2?
<roaksoax> rvba: if you make it so yes
<rvba> roaksoax: ok, apparently we simply populate this file manually in the packaging so I've got my answer.
<roaksoax> rvba: yep, so you'd need to add a new /sed/ in order to replace the second key=value
<rvba> roaksoax: ok, got it,ta
<roaksoax> rvba: but that file already comes with one key value, and the value for that key is being replaced
<rvba> roaksoax: can you please triage this (pretty critical if you ask me)?  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1081212 allenap or I will work on a fix for it.
<ubot5> Ubuntu bug 1081212 in maas (Ubuntu) "The address of the API in pserv.conf (tftp/generator) is http://localhost/MAAS/api/1.0/pxeconfig/" [Undecided,New]
<roaksoax> rvba: is this bug present in the archives?
<rvba> roaksoax: yes
<roaksoax> done
<rvba> ta
<allenap> roaksoax: Could you do the same for bug 1081660 please?
<ubot5> Launchpad bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Undecided,New] https://launchpad.net/bugs/1081660
<roaksoax> allenap: sure thing
<allenap> Ta.
<roaksoax> allenap: weird, that bug didn't happen before
<roaksoax> bigjools: howdy! is bug #1081392 not fixed in 1.4/quantal?
<ubot5> Launchpad bug 1081392 in python-django (Ubuntu) "Include upstream fix for bug 15496" [Undecided,New] https://launchpad.net/bugs/1081392
<bigjools> roaksoax: hi
<bigjools> roaksoax: it's already in quantal
<bigjools> I only noticed the bug on precise
<roaksoax> bigjools: ok cool
<bigjools> roaksoax: note that this particular fix is already in upstream 1.3, but I did a patch as that saves worrying about bringing in many changes if upstream is refreshed
<roaksoax> bigjools: ok cool
<roaksoax> bigjools: yeah we shouldn't have issues for this
<bigjools> roaksoax: did you see https://bugs.launchpad.net/bugs/1081660
<ubot5> Ubuntu bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Critical,Triaged]
<bigjools> ah you did, you triaged it :)
<roaksoax> bigjools: yeah, which i found pretty werid
<roaksoax> cause that error never appeared before
<roaksoax> so unless someone changed something
<roaksoax> bigjools: this is how it handles it: ip=$(ifconfig eth0 | awk '$1 == "inet" { sub("addr:","",$2); print $2; }') && [ -n "${ip}" ] && host=$(dig +short -x $ip)  && host=${host%.}
 * bigjools blinks
<bigjools> roaksoax: I expect it's a genuine timeout and dig is returning that string
 * bigjools reconnecting
<roaksoax> bigjools: yeah that might indeed be the issue, though I've never seen it before :/
<roaksoax> i can't reproduce it
<bigjools> roaksoax: sigstop the dns server?
<bigjools> btw I copied all the packages from experimental to testing
#maas 2012-11-22
<bigjools> roaksoax: out of interest, what does it mean when the main bugtask on those backport requests is marked fix-released?
<roaksoax> bigjools: that's been fixed in ubuntu+1
<bigjools> ah ok trunk
<bigjools> seems a bit weird for a backport request, but ok :)
<roaksoax> bigjools: not trunk, but raring :)
<roaksoax> bigjools: raring/quantal
<roaksoax> so in case we are sruing to quantal, we need it fixed in raring first
<bigjools> it's ubuntu's trunk :)
<roaksoax> bigjools: btw... nick just made changes to the documentation in the latest stabilization ... however, unless the docs build with whatever is in archive, the won't get included in the package
<roaksoax> other than that, maas-import-pxe-file manpage needs to be built now
<bigjools> roaksoax: you mean dependencies?
<roaksoax> bigjools: yeah dependencies in archive
<bigjools> roaksoax: ok I think it should. there were fixes, but I don't recall seeing any n ew deps
<roaksoax> yep, will look into that then
<roaksoax> anyways, i'm off
<lifeless> bigjools: so the idea is that sru only gets things that applied to trunk first. As a process it doesn't understand things that only apply to old versions (such as bugs that architectural improvements made impossible in trunk)
<roaksoax> have a good day
<bigjools> roaksoax: righto, cheers buddy
<bigjools> lifeless: yes, that's understood.  I was just referring to the odd practice with bugs.
<lifeless> bigjools: so was I :P
<bigjools> then we are in violent agreement
<lifeless> \o/
<bigjools> now, time for the a/c, 30C at 11am is too much
<rbasak> allenap: this printf "%s\n" "$@" thing; I had no idea that printf would behave like that, but it does seem to. Is this documented anywhere?
<rbasak> (ie. I can't find it documented anywhere!)
<allenap> rbasak: I can't find it documented anywhere either.
<rbasak> allenap: should I use it anyway?
 * rbasak isn't too bothered by arches starting with hyphens, or arches with spaces in them (although the latter is easy enough to quote)
<allenap> rbasak: Up to you :) Using an undocumented feature of bash's printf doesn't seem like a big problem, given that none of this has tests to spot breakage with echo either ;) It's probably $safer to go with echo, where $safer has yet to be defined in this dimension.
<rbasak> :-)
<roaksoax> bigjools: howdy
<roaksoax> bigjools: https://code.launchpad.net/~allenap/maas/packaging.render-man/+merge/135798
<bigjools> o/
<roaksoax> bigjools: i think that should not land
 * bigjools is all ears
<roaksoax> bigjools: that's getting dependencies for the internet
<bigjools> ?
<bigjools> how's that?
<allenap> Ah, `make man` may do that.
<allenap> roaksoax: Good point.
<bigjools> oh I didn't know it did that
<bigjools> that's quite bad indeedf
<roaksoax> yeah :)
<allenap> It's automatically installing Sphinx via buildout.
<bigjools> so allenap, back to pre-generated man pages? :)
<allenap> bigjools: Yeah :-/
<allenap> Right, shouldn't take long...
<roaksoax> allenap: can't use sphinx from archiveS?
<bigjools> "Julian's change and Gavin's change meet like matter and antimatter"
<bigjools> !
<roaksoax> how woudl you generate those docs manually?
<bigjools> allenap: ah yes you could add sphinx as a build dep
<roaksoax> the problem is that it is setting a build environment
<allenap> Could use sphinx from package I guess. Let me see if that'll work.
<roaksoax> allenap:
<roaksoax> allenap: yes
<roaksoax> allenap: and you need to make sure that the source is not unclean after making it
<bigjools> roaksoax: I pushed a new change up to packaging.precise.sru.  I also set the branch conf to append_revisions_only=True just in case you decided to push without pulling first :)
<roaksoax> bigjools: alright cool :)
<allenap> roaksoax, bigjools: It's a big job to set up the build environment (right now it needs the full Django+MAAS stack build in order to correctly generate docs) so I'm going to go with keeping the generated man pages in the tree.
<bigjools> urgh
<bigjools> ok
<roaksoax> allenap: so yeah we don't want that in the packaging (to buld the whole environment), so I'd recommend you do it in the debian/rules file, (similar to how I build enums.js)
<allenap> bigjools: We can revisit this later; let's do this to unblock the build. Secondly, we could add a test to ensure that the man pages are up-to-date.
<bigjools> allenap: +!
<bigjools> and 1
<allenap> bigjools: https://code.launchpad.net/~allenap/maas/keep-rendered-man-pages/+merge/135800 (no test, but I need to go to bed)
<bigjools> allenap: I'll pick it up, thanks
<allenap> There will be a corresponding package change.
<bigjools> ok
<allenap> bigjools: I've just pushed the packaging change (to not generate the man pages). Night night.
<bigjools> cheers
<bigjools> nn
<allenap> roaksoax: Thanks for spotting that problem so soon.
<bigjools> I'll fix it all up, it'll conflict with mine
<roaksoax> allenap: no worries :) that's the reason why I never built docs before :)
<roaksoax> anyways
<roaksoax> have fun guys
 * roaksoax continues with his holiday
<bigjools> o/
<bigjools> roaksoax: FWIW the trunk packaging had ended up with maas/1.2 in the get-orig-source rule.... oops!
<roaksoax> bigjools: yeah I removed that but I gets got introduced again :S:)
<bigjools> it's fixed in allenap's branch about to land
<roaksoax> ok cool
<bigjools> roaksoax: also I unsubscribed maas-maintainers from branch email - subscribe yourself instead if you want
<roaksoax> bigjools: will do
<roaksoax> thanks
<bigjools> I got fed up with double notifications
#maas 2012-11-23
<bigjools> roaksoax: still around?
<bigjools> daily recipes were screwed up, dunno who had changed them but quantal was actually building trunk so the versions are all wrong and I can't upload the lower 1.2 versions now.  Thinking of bumping the 0.1 to a 0.2
<bigjools> ach, will just do it in the recipe
<allenap> Morning.
#maas 2013-11-18
<Azendale1> So, reading the answer to this question, http://askubuntu.com/questions/361910/to-use-ppa-on-12-04-lts-cloud-image, should I have the cloud archive ppa on my juju client and my MaaS server in addition to specifying it in the openstack charm settings?
<bigjools> Azendale1: not needed in charm settings unless you're deploying apps that require it
<bigjools> but you do need it on juju client and maas server
<Azendale1> bigjools: by "apps that require it" do you mean stuff running in openstack or openstack itself?
<bigjools> Azendale1: I mean whatever you're deploying with juju on top of maas
<Azendale1> bigjools: ah, ok, that would be openstack
<atc3030> bigjools, you remember my question from earlier?
<bigjools> atc3030: I do
<atc3030> can you think of the best way to implement what i was trying to do?
<bigjools> you need to set the interface with the nodes hanging off it as the managed interface
<bigjools> in the maas cluster edit page
<bigjools> you need to configure port forwarding and/or NAT from there to the internet-facing port
<atc3030> i dont need to configure a dhcp server or anything like that on the new interface? maas will handle that?
<bigjools> yes - as long as it's managed, maas will handle it all
<atc3030> port forwarding on the server itself or from the router the head server is connected to?
<bigjools> forwarding between interfaces on the server
<atc3030> ok. thank you
<bigjools> I assume you have something like this:
<atc3030> i was just running out of terms to search for lol
<bigjools> internet <---------eth0> server <eth1----------> nodes
<atc3030> ok. thank you
<AskUbuntu> Can Juju cannot services that are in different environments? | http://askubuntu.com/q/378679
<gmb> allenap: Can I get some love / a review for https://code.launchpad.net/~gmb/maas-test/import-images/+merge/195550?
<gmb> allenap: Oh, sorry, just seen you've claimed it.
<allenap> gmb: Oh bugger, I claimed it before the call then forgot about it. I'll get on it right away.
<gmb> Ta.
<roaksoax> 5~/win 3
<allenap> rvba: What's the direct_network setting for in maas-test?
<jlundy> howdy folks!
<jlundy> anyone about?
#maas 2013-11-19
<jam> mwhudson: poke about your recent patches
<rvba> gmb: I'm done with the commissioning tests; where are you at with the enlistment test?  We should probably briefly talk about that because I suspect those tests are almost identical.
<rvba> Re: "allenap | 17:58:18> rvba: What's the direct_network setting for in maas-test?"
<rvba> allenap: that's the definition of the node's network, the one MAAS' DHCP manages.  If you leave it blank '192.168.2.0/24' will be used, but you might want to use a specific network for some reason, hence the presence of the (optional) parameter.
<rvba> gmb: commissioning *test*
<bigjools> rvba: can gmb give you his tests migration task? I want him to sort out a caching proxy.
<rvba> bigjools: no problem
<gmb> Cool.
<bigjools> rvba: you are great
<gmb> rvba: I haven't gotten much further than the code you passed me yesterday â it was close to my EoD and the MTTF on this has been killing me.
<bigjools> now, I need to know why allenap put "str=None" in the templates for our code
<gmb> bigjools: To force us to use unicode and byte strings?
<bigjools> since I think I need it to convert a byte to a char
<gmb> Ew.
<bigjools> more to the point, I have a bytes buffer from a DHCP server
<bigjools> and 4 of those bytes are an IP address I want to get out of it
<bigjools> str(byte) works perfectly.
<rvba> gmb: all right, no worries.  Like I said, the enlistment test is very similar to the commissioning test.  I'm counting on you for the review though ;)
<gmb> rvba: Deal.
<gmb> rvba: bigjools and I have agreed that I'm about to engage in anger-driven development to make maas-test faster â or at least more informative.
 * gmb *cracks knuckles*
<rvba> Sounds like a very good idea.
 * bigjools winces
<bigjools> rvba: yeah it sounds like you are hacking around slowness at the moment
<rvba> Indeed.
<bigjools> hence me wanting gmb to do this proxy
<bigjools> since I believe that's what everyone said was best ;)
<rvba> I agree :).
<allenap> bigjools: bytes is a synonym for str in Python 2.
<bigjools> allenap: I can't do a straight replacement though, my code fails
<bigjools> good morning BTW
<allenap> bigjools: Morning! Want to share you code and I'll take a look?
<bigjools> allenap: in Python3 I can do:
<bigjools> buffer = b'\x10\x00\x00\xaa'
<bigjools> and then something like
<bigjools> '.'.join(str(byte) for byte in buffer)
<bigjools> et voila I get an IP
<mwhudson> jam: oops, bed time
<jam> mwhudson: np. I think I've queued all your stuff to land
<bigjools> allenap: gah only python3 has an ipaddress module
<rvba> bigjools: just use netaddr then.
<rvba> (If that suits your needs)
<bigjools> rvba: where?
<rvba> What do you mean "where?"?
<bigjools> where is netaddr?
<bigjools> hmm maybe socket.inet_ntoa
<rvba> We use it in MAAS already.
<rvba> http://pythonhosted.org/netaddr/
<bigjools> >>> socket.inet_ntoa(buffer[245:249])
<bigjools> '16.0.0.170'
<bigjools> \o/
<bigjools> allenap: FYI ^
<allenap> bigjools: Yay!
<bigjools> allenap: is it worth me taking the time to make a class look like a byte buffer or should I just stick with a property on the class to get the buffer out ...?
<bigjools> allenap: also this worked: '.'.join('%d' % ord(char) for char in buffer[245:249])
 * bigjools EODs
<allenap> bigjools: Stick a property on.
<gmb> rvba: mass-test took 34m41.123s from start to test_dummy() on Canonistack lcy01. Haven't got timings for individual components yet but packages + PXE files definitely took the longest, anecdotally.
<gmb> That was with trunk, btw.
<rvba> gmb: it took 40m5.924s to running locally (and I don't have the same bandwidth canonistack has *including* the enlistment and the commissioning tests.
<rvba> gmb: care to have a look btw? https://code.launchpad.net/~rvb/maas-test/real-tests/+merge/195748
<gmb> rvba: Interesting. And it looks like uvt-kvm create tends to get stuck in a read() for long periods of time; can't figure out why yet.
<gmb> rvba: Anyway, I'll look at your branch now.
 * gmb -> lunch and errands
<HumpyDumpy> I just installed ubuntu MAAS, logged in for the first time to the web gui, and it says I have no boot images
<HumpyDumpy> how do I get them, do i do it from the gui or from command line?
<HumpyDumpy> cos I don't want to break my srv
<HumpyDumpy> http://pastebin.com/ncnDLfjV
<HumpyDumpy> anyone?
<HumpyDumpy> look at that and help humpy
<HumpyDumpy> it's ok, false alarm... i googled it
<HumpyDumpy> ;D
<matsubara> HumpyDumpy, yes, you can trigger that with the command line or from the gui. (through the cli, run as root maas-import-pxe-files or click the Import boot images in the web ui)
<HumpyDumpy> yay, someone woke up
<HumpyDumpy> what PXE settings do I need in my windows dhcp to make MAAS work?
<HumpyDumpy> OMG how many boot files are there
<HumpyDumpy> >:(
<HumpyDumpy> i got my first srv up and running, trying to add a node to it, the node is accepted and ready to do it's thing, but i can't PXE boot it, it's timing out.
<HumpyDumpy> they talk about avahiboot but i can't find anything on it
<HumpyDumpy> i added in my dhcp the boot ip for the maas srv and filename
<HumpyDumpy> i had to restart the pserv
<HumpyDumpy> ;D
<HumpyDumpy> i got a node installed now
<HumpyDumpy> woot
<bigjools> HumpyDumpy: looking at backscroll, I suggest you read http://maas.ubuntu.com/docs
#maas 2013-11-20
<ashipika> Good day MaaS
<ashipika> Just testing MaaS on Ubuntu 13.10.. Three computers, one installed with ubuntu server 13.10, MaaS - create new, configure dhcp, etc. Commisioned other two computers as nodes (raring, wake on lan, since i do not have IPMI), accepted.. Now it looks like it is installing.. But all i see is a blank screen and after a while, the node shuts down. Is this what is expected?
<ashipika> oh, and the status of the node still says: Allocated to...
<Azendale> Does anyone know how of any log Curtin uses that I can look at? I'm trying to figure out the root cause of https://bugs.launchpad.net/curtin/+bug/1253111
<ubot5> Ubuntu bug 1253111 in curtin "Juju on MaaS fails to bootstrap when MaaS uses the curtin installer on the node" [Undecided,New]
<rvba> Azendale: the two things I can think about are: /var/log/maas/rsyslog/<ip_or_machine_name> or the node's console when curtin tries to install the machine.
<rvba> Azendale: maybe smoser will be able to help since he's the maintainer of curtin.
<rvba> (he does not seem to be around right now, but you can probably try to ping him later if he doesn't respond on the bug you've filed.)
<Azendale> rvba: thanks. I can't see any log file for that node, but I'll give it another try and see. I actually was talking with smoser in one of the vuds sessions a few minutes ago (about something else)
#maas 2013-11-21
<rvba> gmb: I'm sorry to dump this on you like that, but I've got a couple of branches up for review if you fancy doing some reviewing :).
<rvba> https://code.launchpad.net/~rvb/maas-test/bmc-params-1/+merge/196107
<rvba> https://code.launchpad.net/~rvb/maas-test/bmc-params-2/+merge/196108
<rvba> https://code.launchpad.net/~rvb/maas-test/bmc-params-3/+merge/196109
<gmb> rvba: No problem, I'll look now.
<rvba> https://code.launchpad.net/~rvb/maas-test/bmc-params-4/+merge/196111
<gmb> Er mah gerd
<rvba> heh
<gmb> This is like opening one of the internet's tubes and blasting it in you face.
<rvba> gmb: on the bright side, each branch is simple and well focused :)
<gmb> +!
<hazmat> roaksoax, is there any documentation on the maas with vbox setup you demo'd @ the cloud sprint
<roaksoax> hazmat: there's none with vbox, but there's one with virt-manager
<hazmat> roaksoax, where at?
<roaksoax> hazmat: http://insights.ubuntu.com/resources/article/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
<hazmat> roaksoax, thanks
<jamespage> allenap, are you guys targetting python3 support this cycle?
<jamespage> roaksoax, ^^
<roaksoax> jamespage: nope
<roaksoax> jamespage: yes and no
<jamespage> preparation rather than by default I suspect
<roaksoax> jamespage: work has already started to happen upstream, but i think django is the concern or some other deps
<roaksoax> jamespage: yes the preparation has already started
<bigjools> jamespage: yes yes yes. Depends on dependencies but we want to do it.
#maas 2013-11-22
<jajajl> test
<jtv> bigjools: any idea why the pserv test suite is breaking with "No module named testing.credentials"?
<bigjools> jtv: it is?
<bigjools> my branch just landed ok
<jtv> Ah!  I had apiclient installed on the system.
<jamespage> bigjools, thats good news
<bigjools> jamespage: it *might* be good news :)
<jamespage> openstack won't make it this cycle so we will retain a server dependency on python2
<rvba> Someone up for a tiny review? https://code.launchpad.net/~rvb/maas-test/add-log-files/+merge/196252
<rvba> jtv: I'll review your branch.  Maybe you can have a look at mineâ¦ it's tiny.
<jtv> Sure.
<jtv> rvba: be careful saying "disposed of."  Julian might charge you with Terminal Preposition.
<jtv> To which I say:
<jtv> bollocks, off which to fuck.
<jtv> (Smiley is clear there, right?)
<AskUbuntu> juju status machines 1 2 3 instance-id: pending forever | http://askubuntu.com/q/380716
<AskUbuntu> OpenStack Havana with Juju/MAAS : no Quantum API server listening for requests | http://askubuntu.com/q/380718
<Andrei__> Hello
<Andrei__> can someone help me with OpenStack Havana?
<mfisch> I have a question about adding a MaaS node from a server CD. I booted the CD, selected MaaS, it found the master node, I hit enter. and then it powered off.
<mfisch> I'm missing something because it's obviously not done
<mfisch> and there's my node, it just wasnt done yet, so nm
<AskUbuntu> maas-cli login always returns 403 Forbidden | http://askubuntu.com/q/380833
<Jay___> Can you deploy windows on the MAAS platform?
<Jay___> Hello
<mfisch> Jay___: I'd like to know the answer too, maybe use askubuntu.com to ask if you don't get an answer here? I think that the answer is no however
<kentb> in the v-uds session on maas plans for 14.04, there was talk of implenting some HA functionality.  I heard talk of making the region controllers HA-capable, but, what about the cluster controller?
#maas 2013-11-23
<wes_> can someone help me with a raxmon error i'm getting?
<wes_> Exception: {u'txnId': u'.rh-MxWP.h-dfw1-maas-prod-api1.r-Y9MyCEbd.c-11543163.ts-1385174726244.v-0c711e4', u'message': u'Rackspace Cloud Server entities may not be deleted', u'code': 403, u'type': u'forbiddenError', u'details': u'Rackspace Cloud Server entities may not be deleted'}
<AskUbuntu> adding nodes to MAAS server?. . | http://askubuntu.com/q/381235
#maas 2013-11-24
<bigjools> kentb: no plans for the clusters, you just add more of them and get HA that way
#maas 2014-11-17
<randomjoe> Hi, Is there any documentation on how to setup MAAS (region controller) to be highly available. This is what seems to be indicated in this link http://maas.ubuntu.com/docs/orientation.html#a-typical-maas-setup however documentation on this is thin to non-existent
#maas 2014-11-18
<caribou> I would need someone to sponsor LP: #1346703 for an SRU to Trusty
<ubot5> Launchpad bug 1346703 in maas (Ubuntu Trusty) "/var/log/maas/rsyslog has incorrect permission" [Medium,In progress] https://launchpad.net/bugs/1346703
<caribou> it has now made it to Utopic
<bigjools> roaksoax: ^ ?
#maas 2014-11-21
<chrome0_> i would like to change the install target disk for curtin, does anyone have any pointers?
<chrome0_> ie. it seems to pick /dev/sda by default; i'd need to install onto another disk though
<chrome0_> any pointers?
#maas 2015-11-16
<nitin_> I have an issue!!
<nitin_> After uploading CentOS images, the cluster controller is not syncing automatically
<nitin_> How to start syncing manually?
<dimitern> nitin_, assuming you still use maas 1.7, have you tried following this guide: http://maas.ubuntu.com/docs1.7/os-support.html#installing-maas-images ?
<nitin_> dimitern, yes i have uploaded CentOS images using the commands given in the guide: http://maas.ubuntu.com/docs1.7/os-support.html#installing-maas-images
<dimitern> nitin_, and your cluster shows "out-of-sync" ?
<nitin_> yes
<nitin_> actually, the CentOS images supported by MAAS are syncing successfully
<nitin_> but, my own custom image of CentOS is not able to sync
<nitin_> perhaps its large size of around 1.4 GB might be causing the problem
<dimitern> nitin_, I doubt the size is a problem
<dimitern> nitin_, what do you mean your custom image?
<dimitern> nitin_, if you uploaded (a supported by maas - look in the docs about the maas-image-builder) custom image what's there to sync?
<dimitern> nitin_, try maas <profile> boot-images import ?
<nitin_> i want to upload a CentOS 6.3 image with certain packages & applications
<dimitern> nitin_, I haven't tried what you're trying to do, sorry :/
<nitin_> Do I need to build the image using MAAS Image Builder
<dimitern> nitin_, but some of the guys from the maas team should be able to help you << blake_r, roaksoax, mpontillo,
<nitin_> ok..thanks dimitern!!
<mup> Bug #1515276 changed: Error creating a bond <MAAS:New for andreserl> <https://launchpad.net/bugs/1515276>
<mup> Bug #1516722 opened: MAAS 1.9 fails install <MAAS:New> <https://launchpad.net/bugs/1516722>
<los> Had MaaS working....borked images ... how?  Gak
<los> (Checked DNS, IP, its all working...I swear this was working on Fri.)
<los> Got my MaaS up and going, but, the Images tab is stuck in "Apply Changes".  No good clues in log.
<roaksoax> los: what do you mean stuck in apply changes ?
<los> I click the Apply changes button, and I see in the log there's traffic out com.ubuntu.maas:v2 API etc....and then after "Region import" or sometimes skipping that POOF back to Apply Changes (with the versions/archs showing)
<los> My nodes "are Ready" etc.
<los> Its weird, I see the region controller hit ubuntu's site to check versions...I wonder.
<mup> Bug #1467995 changed: Simultaneous Trusty deployments to VMs with SATA virtual disks on same physical drive fail sometimes - drops to Grub rescue shell <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1467995>
<mup> Bug #1467995 opened: Simultaneous Trusty deployments to VMs with SATA virtual disks on same physical drive fail sometimes - drops to Grub rescue shell <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1467995>
<mup> Bug #1467995 changed: Simultaneous Trusty deployments to VMs with SATA virtual disks on same physical drive fail sometimes - drops to Grub rescue shell <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1467995>
<los> roaksoax: found your site, :) ....still pondering logs.
<roaksoax> los: so what about if you rm -rf /var/lib/maas/boot-resources/ and restart he import ?
<los> roaksoax: Aha!  I did that and sure enough a different snapshot started coming down...its appearing to be "complete" but since I zapped my other one I can't compare :0
<los> (your site is the ONLY place I've [just] found that has the "lifecycle" of En->Com->Ready, argh!)
<los> I see it talking to ubuntu about objects: 2015-11-16 16:39:57 [sstreams] INFO: com.ubuntu.maas:v2:download/com.ubuntu.maas:v2:boot:14.04:amd64:hwe-v: to_add=[u'20150727'] to_remove=[]
<los> Followed by GET's: 2015-11-16 16:40:17 [-] 127.0.0.1 - - [16/Nov/2015:22:40:17 +0000] "GET /MAAS/images-stream/ubuntu/amd64/hwe-v/trusty/20150727/root-image.gz
<los> iptraf shows bytes coming down...
<los> Oh! I am on Step 2/2, that's new, haven't change anything...!  Weird!
<los> (hasn't gotten past step 1/2 all day)
<roaksoax> los: yeah weird, something must have borkjed and maas thought it had the images
<los> roaksoax: Third time I've blown them away.  Dang.  Thanks for the magical juju.  Couldn't find any system status page for centralized maas (ubuntu) pages
<los> roaksoax: LOL: Doomed: I celebrated too early....it took longer but got back to the same place.  Interestign!
<roaksoax> los: do you have access to the ubuntu archive ?
<mup> Bug #1516815 opened: MAAS creates DNS record against Alias when it is part of the PXE interface <MAAS:New> <MAAS 1.9:New> <MAAS trunk:New> <https://launchpad.net/bugs/1516815>
<los> roaksoax: I don't think so--I haven't signed up for it, if its not public access etc.
<roaksoax> los: it is public access
<roaksoax> los: are you agaisnt a proxy ?
<roaksoax> behind*
<los> roaksoax: I'll look it up--I've seen you (noproxy) guys use it in the videos
<los> roaksoax: (Get latest from dev trunk?)
<roaksoax> los: what version are you using?
<mup> Bug #1516815 changed: MAAS creates DNS record against Alias when it is part of the PXE interface <MAAS:New> <MAAS 1.9:New> <MAAS trunk:New> <https://launchpad.net/bugs/1516815>
<los> roaksoax: 1.8.3+bzr4053
<roaksoax> los: you wanna try 1.9.0rc1 ? ppa:maas/next
<los> roaksoax: Sure.  I'm also having trouble getting a 2nd Cluster Controller to talk to the existing RegCntrl.  This is researchy, for the sake of JuJu :)
<los> roaksoax: can you install just a ClusCntrl by itself?  The RegCntrl web berzerk when I changed the ClusCntrl2's shared secret to the RegCntrl1's secret (db/flatfile mismatch from googling)
<roaksoax> los: you can try to dpkg-resource maas-cluster-controller and paste the shared secret for the cluster to connect
<los> roaksoax: 1) add archive 2) update/upgrade?
<roaksoax> los: sudo add-apt-repository ppa:maas/next && sudo apt-get update && sudo apt-get dist-upgrade
<los> roaksoax: Yeah, the Regional was going bonkers hitting the log 1/sec.  Thx!
<mup> Bug #1516815 opened: MAAS creates DNS record against Alias when it is part of the PXE interface <MAAS:New> <MAAS 1.9:New> <MAAS trunk:New> <https://launchpad.net/bugs/1516815>
<los> roaksoax: Yeah, this on 15.10 (latest) also btw
<mup> Bug #1516815 changed: MAAS creates DNS record against Alias when it is part of the PXE interface <MAAS:Incomplete> <MAAS 1.9:Incomplete> <MAAS trunk:Incomplete> <https://launchpad.net/bugs/1516815>
<mup> Bug #1516815 opened: MAAS creates DNS record against Alias when it is part of the PXE interface <MAAS:New> <MAAS 1.9:New> <MAAS trunk:New> <https://launchpad.net/bugs/1516815>
<los> roaksoax: "Dependency problems prevent..." maybe I should nail the maas pkgs out?
<los> roaksoax: Weird, did it on two hosts and only one error'd
<los> roaksoax: Looks like django db migration problem:
<los> django.db.utils.ProgrammingError: column maasserver_vlan.mtu does not exist LINE 1: ...erver_vlan"."vid", "maasserver_vlan"."fabric_id", "maasserve...
<los> dpkg: error processing package maas-region-controller (--configure):  subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of maas:  maas depends on maas-region-controller (= 1.9.0~rc1+bzr4496-0ubuntu1~wily1); however:   Package maas-region-controller is not configured yet.
<los> roaksoax:Order of dependency?
<los> roaksoax: I had removed maas-region-controller and had said "no" to the dbconfig-common dependency removal.
<thetrav> heya folks
<thetrav> Will MaaS behave itself if my Nodes are not able to view the region controller?
<thetrav> is it ok for them to only see the cluster controller?
<los> thetrav: I don't know, but, I'm building a 2C1R setup myself and I am wondering if there is connectivity issues between C2 and R1
<los> thetrav: C1 and R1 are on the same box
<thetrav> yeah, I'm building the same
<thetrav> I'm actually trying to set R1, C1 & C2 on the same physical host but in VMs.  The box has 3 Nics and it's "important" that the networks C1 and C2 manage don't see each other
#maas 2015-11-17
<los> thetrav: I hear you, for my own sanity, I'm setting something up just like that right now.  VirtualBox, on top of (they give me) Windows 7.
<los> roaksoax: thanks for the clues!
<los> I am using the archive latest version as per roaksoax's suggestions.  I want to replicate the 2C+1R setup at home tonite for my own amusement.  I've gotten a single 1C+1R working, doing JuJu on it, fine.  Want to see the 2C.
<los> roaksoax: thetrav: there looks to be a leak of a Django user even if I were to remove the 1.8.3 maas entirely.  The 1.9.0rc1 won't install due to the user still being there (mysteriously after (to be weird) remove all the django packages too)...no psql database hanging around either.
<thetrav> I tend not to remove packages
<thetrav> disposable vm's
<thetrav> ansible to get them from OS install to whatever state I need
<thetrav> mind you MaaS is a bit shit for that
<thetrav> I needed to dig around in their DB to get the API key
<los> thetrav: I hear you, I'm just messing around right now.  Just rebuilt some more VM's (by hand for now).  I'm messing around.  Done for now.  Thanks for assistance!
<nitin_> Please help me with my query at :http://askubuntu.com/questions/698642/how-to-generate-a-custom-image-of-centos-for-maas
<mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1516891>
<mup_> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1516891>
<vlaza> hello everyone; short question: will there be any HA feature in 1.9.0 version ? I'm interested in relation to region-controller
<roaksoax> vlaza: that should come out in 2.0 actually
<vlaza> roaksoax: thank you for the info
<dimitern> mpontillo, FYI - https://bugs.launchpad.net/maas/+bug/1517097
<mup> Bug #1517097 opened: MAAS acquire interfaces argument should AND key-value pairs for the same label <MAAS:New> <https://launchpad.net/bugs/1517097>
<mup> Bug #1517129 opened: vg has insufficient free disk space <MAAS:New> <https://launchpad.net/bugs/1517129>
<mup> Bug #1517180 opened: No support for adding custom certificate chains <cloud-installer> <MAAS:New> <https://launchpad.net/bugs/1517180>
<mup> Bug #1517180 changed: No support for adding custom certificate chains <cloud-installer> <MAAS:New> <https://launchpad.net/bugs/1517180>
<mup> Bug #1517180 opened: No support for adding custom certificate chains <cloud-installer> <MAAS:Triaged> <https://launchpad.net/bugs/1517180>
<mup> Bug #1517221 opened: subnet does no longer show DNS servers <MAAS:New> <https://launchpad.net/bugs/1517221>
<mup> Bug #1517221 changed: subnet does no longer show DNS servers <MAAS:New> <https://launchpad.net/bugs/1517221>
<mup> Bug #1517221 opened: subnet does no longer show DNS servers <MAAS:New> <https://launchpad.net/bugs/1517221>
<mup> Bug #1517227 opened: deploy fails with non-default partitioning <MAAS:New> <https://launchpad.net/bugs/1517227>
<mup> Bug #1517227 changed: deploy fails with non-default partitioning <MAAS:New> <https://launchpad.net/bugs/1517227>
<mup> Bug #1517227 opened: deploy fails with non-default partitioning <MAAS:New> <https://launchpad.net/bugs/1517227>
#maas 2015-11-18
<mup> Bug #1517350 opened: with special charcters in password of esxi host virsh login fails <maas-cli> <MAAS:Triaged> <https://launchpad.net/bugs/1517350>
<gawful> (is the server bugged for logins?  I can't auth as myself "los")
<gawful> MaaS 1.9.0rc1 is amazing!
<mgz> you can't log in, but it's amazing? :P
<los_> lol...sep'ly I couldn't log in as los here, and it logged me in as los_
<los_> I noticed a few people in the same boat, was aronwdering.
<los_> MaaS 1.9.0rc1 has a huge number of new things in it.  Surprising.
<los_> s/aronw/wond
<los> Aha,my-bad-as-always-its-my-bad
<los> Looks like 1.9.0rc1 is not seeing cores allocated in the case of VirtualBox for node creation, even after repeated Commissioning.
<los> Not seeing cores > 1
<roaksoax> los: maybe the VM is not commissioning successfuly? If VirtualBox is not exposing thatto the OS the way actual hardware does, then that is a bug
<roaksoax> we don't really test against VBox VM's as it is not officially supported
<los> roaksoax: thanks.  I am sure you're right...its a virtualbox->OS failure to communicate <banjos>
<los> roaksoax (BUT 1.9.0rc1 is an astounding pile of new features!)
<roaksoax> los: hehe, thanks! 2.0 should be more exciting then :)
<los> roaksoax: part of the fun was figuring out what tools y'all were using in your vids.  Here's some of them and more: http://www.beisner.com/corp/remote-linux-server-admin-tools-byobu-htop-nethogs-nload-and-iptraf/
#maas 2015-11-19
<mup> Bug #1517687 opened: Partition cannot be saved; not enough free space on the block device. <MAAS:New> <https://launchpad.net/bugs/1517687>
<mup> Bug #1517687 changed: Partition cannot be saved; not enough free space on the block device. <MAAS:New> <https://launchpad.net/bugs/1517687>
<mup> Bug #1517687 opened: Partition cannot be saved; not enough free space on the block device. <MAAS:New> <https://launchpad.net/bugs/1517687>
<pmatulis> how do i deploy a node using the cli?
<mgz> roaksoax: https://bugs.launchpad.net/juju-core/+bug/1412621
<roaksoax> mgz: https://bugs.launchpad.net/juju-core/+bug/1516891
<mgz> roaksoax: https://bugs.launchpad.net/juju-core/+bug/1412621/comments/40 frobware replied with some details
<los> Q: How do I get on the webinars?
<mup> Bug #1517227 changed: deploy fails with non-default partitioning <MAAS:Invalid> <https://launchpad.net/bugs/1517227>
<mup> Bug #1517227 opened: deploy fails with non-default partitioning <MAAS:Invalid> <https://launchpad.net/bugs/1517227>
<mup> Bug #1517227 changed: deploy fails with non-default partitioning <MAAS:Invalid> <https://launchpad.net/bugs/1517227>
<mup> Bug #1518067 opened: commissioning fails with bonded interface <MAAS:New> <https://launchpad.net/bugs/1518067>
<mup> Bug #1518067 changed: commissioning fails with bonded interface <MAAS:New> <https://launchpad.net/bugs/1518067>
<mup> Bug #1518067 opened: commissioning fails with bonded interface <MAAS:Incomplete> <https://launchpad.net/bugs/1518067>
#maas 2015-11-20
<pmatulis> how do i deploy a node using the cli?
<pmatulis> (v.1.8)
<mup> Bug #1518226 opened: Option to add ipmipower args via webUI <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1518226>
<caribou> Hello, is anyone familiar with how the booloading (BIOS/UEFI) is handled in Maas ?
<nagyz> hi guys
<nagyz> I'm trying to figure out what happens when I have a server on two MAAS-managed networks (one provisioning, one "public")
<nagyz> it seems to be that the default gateway will be set based on which interface is the first one in the alphabet :-)
<nagyz> same for DNS
<matt_dupre> Hi: I've just upgraded from 1.5 to 1.8.3, but I'm now seeing 503 errors trying to connect to http://<server>/MAAS/
<matt_dupre> The apache error log says "Connection refused [...] attempt to connect to 127.0.0.1:5240 (localhost) failed".  Nothing's listening on port 5240.  Does anyone have any ideas what this could be?
<Haris> hello all
<Haris> what's maas for ubuntu ?
<Haris> is it something like .. if I needed running 2 or more VMs on the same machine, and I didn't have vmware, I'd use maas to do it ?
<Haris> os is it like a PXE ?
<roaksoax> Haris: MAAS is a deployment tool, that not only deploys Ubuntu but other operating systems
<Haris> so, its a PXE ?
<Haris> replacement ?
<roaksoax> Haris: it does PXE, UEFI, Grub net booting
<roaksoax> Haris: but it is not a "PXE replacement"
<roaksoax> Haris: PXE is an underlying technology
<Haris> I see
<Haris> is maas a web tool ?
<Haris> or just the front end
<roaksoax> Haris: maas provides a WebUI and a CLI, so you can do the same thing via those two interfaces
<roaksoax> Haris: so it is a software tool that incorporates other technologies (PXE, DHCP, DNS< Proxy), and provides users with a WebUI and a CLI Interface to control it
<Haris> ah ok
<Haris> cool
<mup> Bug #1518226 changed: Option to add ipmipower args via webUI <canonical-bootstack> <MAAS:Opinion> <https://launchpad.net/bugs/1518226>
<mup> Bug #1518226 opened: Option to add ipmipower args via webUI <canonical-bootstack> <MAAS:Opinion> <https://launchpad.net/bugs/1518226>
<Haris> thank you all
<mup> Bug #1518226 changed: Option to add ipmipower args via webUI <canonical-bootstack> <MAAS:Opinion> <https://launchpad.net/bugs/1518226>
<tinks> quit
<matt_dupre> So I figured by problem above out: /var/log/maas/maas.log was owned by syslog, but the user responsible for logging changed during the upgrade to maas, so maas-regiond was unable to write to the log
<matt_dupre> s/by/my/
<los> Has anyone ever noticed that when you do dpkg-reconfigure on a cluster controller (without a regional) to point to a regional somewhere else....it might "ignore" your URL to the API and try the lo and another address 10.0.2.15?
<los> I can lynx the API and get a login from this VM, no problem, but the logs don't mention failing to connect to my URL I put into the reconfigure.
<los> ...and dpkg-reconfigure maas-cluster-controller takes a really long time to initially start and get into the CUI, if that's a clue
<los> The 10.0.2.15 is one of the local interfaces
<roaksoax> los: do you have an examepl?
<roaksoax> los: or a pb ?
<los> roaksoax:pb?
<los> roaksoax: 2015-11-20 09:55:56-0600 [Uninitialized] Event-loop maasr6:pid=1101 (127.0.0.1:5251): Connection was refused by other side: 111: Connection refused. 2015-11-20 09:55:56-0600 [Uninitialized] Event-loop maasr6:pid=1101 (10.0.2.15:5251): Connection was refused by other side: 111: Connection refused. 2015-11-20 09:56:26-0600 [-] Event-loop maasr6:pid=1101 (192.168.66.1:5251): User timeout caused connection failure.
<los> Even though I've set the MAAS API URL to something totally different, its not in those clusterd.log 's
<los> roaksoax: Even though I can Lynx to that URL no problem, login, see stuff etc. from that same host
<los> roaksoax: the cluster-only host has that 10.0.2.15 address
<los> roaksoax: I read the logs as "I'm gonna connect to localhost on a few ports to see a regional, and I'll try my own IP"
<los> roaksoax: But I can't find that IP in any grep-able file
<roaksoax> los: /etc/maas/clusterd.conf is where the cluster knows where to contact the region controller
<roaksoax> .win 22
<los> roaksoax: looking
<los> roaksoax: It has the right URL.  I will bounce server.
<los> roaksoax: .win 22 = Old Yeller Headache?
<los> roaksoax: as one pal of my says, "Kevork it"
<roaksoax> los: so it has the right URL where to connect to MAAS Region ?
<los> roaksoax: yep
<roaksoax> los: did you add a shared secret ?
<los> roaksoax: yep, even the right one :)
<los> (this time)
<roaksoax> los: that's strange there, shows that it failed due to a timeout
<los> roaksoax: I thought the key part that was interesting is that the 10.13.x.x host I have the regional+cluster ("R+C1") is not mentioned.  This is the 2nd attempted cluster controller ("C2")
<los> roaksoax: I'm assuming "if you can lynx it and get a login, you're good"
<los> roaksoax: Ohhhhhhh I bet the API doesn't work with the port specifier?
<los> roaksoax: (If that's the case the logging is bugged)
<roaksoax> los: what does your clusterd.conf show ?
<los> roaksoax: cluster_uuid: eea5c60a-4fcc-41a4-b141-30ca1b77c177 maas_url: http://10.13.0.6:8946/MAAS
<los> (two lines)
<roaksoax> http://10.13.0.6:8946/MAAS -> http://10.13.0.6:5240/MAAS
<los> roaksoax: clusterd.conf owned root, group maas, 640
<roaksoax> los: or: http://10.13.0.6/MAAS
<los> roaksoax: 8946->80
<los> roaksoax: Its in a VM under Vbox, I know, not supported, but its what I got :)
<roaksoax> los: right so the region binds to 5240, buyt apache is there to proxy from 80->5140
<roaksoax> los: right so the region binds to 5240, buyt apache is there to proxy from 80->5240
<los> roaksoax: ok, cool, so I'm forwarding in 8946 on the vmhost to the vm's 80...should I forward more?  Is there some reverse DNS problem?  Why is the clusterd not logging a connection attempt?  (no sign it "sees" the MAAS API Url as set by dpkg-reconfigure)
<los> Is it a problem that the clusterd is otherwise not configured....aka, the 2nd interface on the C2 VM hasn't been setup yet
<roaksoax> los: my guess is that the forwarding is interfering here
<los> roaksoax: Can you give me an idea of the forwarding requirements?  5240->5240?
<roaksoax> los: yeah I'd do that
<los> roaksoax: using iptraf: can see local socket connection attempts to local ip 10.0.2.15 on ports 5250, 5253, now 5252
<los> roaksoax: I have those forwarded on the R+C1 vm, but, that's the wrong IP.  Its "ignoring my MAAS API" and trying local
<los> roaksoax: On the R+C1 vm host, I have 5250-3 forwarded into the R+C1 vm but no traffic on that
<mup> Bug #1518067 changed: multi-network node could get wrong default gateway that prevents deploy <MAAS:Invalid> <https://launchpad.net/bugs/1518067>
<los> roaksoax: This is interesting:
<los> ââ10.0.2.15:39872                                            =       5           300   S---      eth0     â ââ192.168.66.1:5251                                          =       0             0   ----      eth0     â
<los> ââ192.168.66.1:5251                                          =       0             0   ----      eth0     â
<los> iptraf shows it making a connection from the NAT side network, to an address that I've used for things before but don't have in /etc/network/interfaces at all
<los> roaksoax: I have eth0, enp0s8, and lo....s8 is totally unconfigured.
<los> roaksoax: Ok, I configured the enp0s8 network (That will be the private MaaS network) now I'm getting the connection refused msgs 1/sec, but just the two last ones, the 'refused by other side'
<los> roaksoax: The third (first showing) message with "Timeout" is gone
<los> roaksoax: And...now the dpkg-reconfigure maas-cluster-configure is not slow to start!  Aha!
<los> roaksoax: Changed the URL to 10.13.0.6/MAAS and now I get a fast fail from twisted.... 404
<los> roaksoax: Aha, totally different clusterd.log, after changing the URL to 10.13.0.6:5240/MAAS and having the 5240->5240 mapping
<los> 2015-11-19 13:41:08-0600 [-] Site starting on 5248 2015-11-19 13:41:08-0600 [-] TFTP starting on 69 2015-11-19 13:41:08-0600 [-] Starting protocol <tftp.protocol.TFTP instance at 0x7f06b03b8998> 2015-11-19 13:41:08-0600 [-] TFTP Listener started at 127.0.0.1:69 2015-11-19 13:41:08-0600 [-] TFTP starting on 69 2015-11-19 13:41:08-0600 [-] Starting protocol <tftp.protocol.TFTP instance at 0x7f06b03b8cf8> 2015-11-19 13:41:08-0600 [-] TFTP Lis
<los> 2015-11-19 13:41:08-0600 [Uninitialized] Region not available: Connection was refused by other side: 111: Connection refused. (While requesting RPC info at http://localhost:5240/MAAS/rpc/)
<los> roaksoax: iptraf now shows its reaching out to the right 10.13.0.6!  Closer!
<los> roaksoax: On the R+C1 machine, Apache says: Nov 20 11:03:39 maasr6 sh[1091]: 2015-11-20 11:03:39 [-] 127.0.0.1 - - [20/Nov/2015:17:03:38 +0000] "GET /MAAS/rpc/ HTTP/1.0" 2 00 364 "-" "provisioningserver.rpc.clusterservice.ClusterClientService"
<los> roaksoax: 2015-11-20 11:06:29-0600 [Uninitialized] Region not available: Connection was refused by other side: 111: Connection refused. (While requesting RPC info at http://10.13.0.6:5240/MAAS/rpc/).
<los> Better...but not good
<roaksoax> los: right, so that means the cluster, for whatever reason, can't reach to the region
<los> roaksoax: On the R+C1 machine, when I curl localhost:5240 I get <html>     <head>         <meta http-equiv="refresh" content="0;URL=MAAS/">     </head>     <body bgcolor="#FFFFFF" text="#000000">     <a href="MAAS/">click here</a>     </body> </html>
<roaksoax> los: might be the forwarding
<los> roaksoax: On C2 machine I get ConnRefused so I'm baffled but on it
<los> For the good of all MaaSKind, lolz
<roaksoax> los: this is what happens, the cluster connects to region on that IP/port, and the Region tells the cluster "this are my 4 endpoints, on different ports, because I have multiple daemons running"
<roaksoax> los: so that's the problem I'd think
<roaksoax> los: the cluster cannot connect to the endpoints
<los> roaksoax: Do I need to forward a range of ports, 5240-X -> 5240-X?
<roaksoax> los: "Firewall ports for Region and Cluster controller communication
<roaksoax> The communication between Region and Cluster controller is now limited to use the ports between 5250 and 5259. For all of those users who are using a remote cluster (not running on the same machine as the MAAS Region Controller), need to ensure that these ports are open in the firewall."
<los> roaksoax: Aha, forsooth!
<los> roaksoax: Ok, curl to the 5240 is getting me the "click here" html"
<los> roaksoax: Ok, I get this msg 3x: 2015-11-20 11:26:04-0600 [Uninitialized] Event-loop maasr6:pid=1096 (127.0.0.1:5252): Connection was refused
<roaksoax> uhmm
<los> roaksoax: ...but the IP changes: I get back a 10.0.2.15, which is (I'm thinking) dispensed by the regional, which is an unroutable
<los> roaksoax: So, "Oh, I contact the regional, and it gave me an address and I'm gonna connect and its no good, try these other interfaces address he gave me and loopback too"
<roaksoax> bladernr_: ^^
<roaksoax> err
<roaksoax> blake_r: ^^
<los> roaksoax: I appreciate the help: I recognize this is all virtualbox hooey
<roaksoax> blake_r: any ideas? seems that region might be sending back loopback to cluster ?
<los> roaksoak: I changed the local private maas nets on both the R+C1 machine and C2 machines to non-192.168.66.x addresses (.44 and .88) and then it went bonkers.  Log ceased...a couple timeouts...long pauses...so I'm bouncing both hosts
<los> roaksoax: Ok, this is cool: the .88 address is showing up in the C2 machine's logs, so R+C1 machine is dispensing it back to the C2 machine, ergo, this is all a consequence of the virtual box and unroutables
<los> roaksoax: Clear as a day, the Regional is passing back ALL the interfaces addresses that are non-loopback, and then the Cluster controller is trying them all....I see iptraf on the C machine attempting to connect out to 192.168.88.1, which is the R+C1 machines private MaaS network for the "dummies" to boot off.
<los> of
<los> Roaksoax: taking lunch.  Will work this more when I get back.  Will be looking at netstat to see what's listening on the R+C1 box, etc.
<mup> Bug #1518414 opened: NVMe model info/serial number is not seen <MAAS:New> <https://launchpad.net/bugs/1518414>
<mup> Bug #1518414 changed: NVMe model info/serial number is not seen <MAAS:New> <https://launchpad.net/bugs/1518414>
<mup> Bug #1518414 opened: NVMe model info/serial number is not seen <MAAS:New> <https://launchpad.net/bugs/1518414>
<los> roaksoax: So my region controller is just happy as can be: 2015-11-20 13:35:03 [-] 127.0.0.1 - - [20/Nov/2015:19:35:02 +0000] "GET /MAAS/rpc/ HTTP/1.0" 200 364 "-" "provisioningserver.rpc.clusterservice.ClusterClientService"
<los> roaksoax: should that be on the loopback?
<los> roaksoax: hahahaha the R+C1 machine has localhost:5240 in its cluster controller config!
<los> roaksoax: Wow: I provisioned the R+C1 machine with two interfaces, and I config'd the maas-region-controller with that (NAT outbound) interface up and the other one (MaaS private) unconfigured and its my bad...MaaS picked the only up network as the private one
<los> roaksoax: I get one of these when I trigger a restart through dpkg: 2015-11-20 13:53:20-0600 [HTTPPageGetter,client] Region is not advertising RPC endpoints.
<mup> Bug #1518440 opened: tgt fails to install in LXD <MAAS:Triaged> <tgt:New> <tgt (Ubuntu):New> <https://launchpad.net/bugs/1518440>
<mup> Bug #1518440 changed: tgt fails to install in LXD <MAAS:Triaged> <tgt:New> <tgt (Ubuntu):New> <https://launchpad.net/bugs/1518440>
<los> roaksoax: Doc bug: right above this link, the sentence just.... https://maas.ubuntu.com/docs/install.html#disc-install
<mup> Bug #1518440 opened: tgt fails to install in LXD <MAAS:Triaged> <tgt:New> <tgt (Ubuntu):New> <https://launchpad.net/bugs/1518440>
<mup> Bug #1518440 changed: tgt fails to install in LXD <MAAS:Triaged> <tgt:New> <tgt (Ubuntu):New> <https://launchpad.net/bugs/1518440>
<mup> Bug #1518440 opened: tgt fails to install in LXD <MAAS:Triaged> <tgt:New> <tgt (Ubuntu):New> <https://launchpad.net/bugs/1518440>
<nagyz> can someone enlighten me how would you manage DNS if you have two different subnets, like an internal and an external?
<nagyz> if a node has IPs on both... currently MAAS only registers the A record for the alphabetically first interface
#maas 2015-11-21
<mup> Bug #1518633 opened: Internal server error on "bad" ipv6 netmask <MAAS:New> <https://launchpad.net/bugs/1518633>
#maas 2016-11-21
<mup> Bug #1643403 opened: [2.1.1] regiond requests to 127.0.0.1:5240 going via external proxy and failing <MAAS:New> <https://launchpad.net/bugs/1643403>
<mup> Bug #1643552 opened: API renderings do not contain fields necessary to construct self-referential URI <api> <MAAS:Triaged> <https://launchpad.net/bugs/1643552>
<mup> Bug #1643595 opened: [3.0] Drop escape.shell from preseed.py <MAAS:Confirmed> <https://launchpad.net/bugs/1643595>
<wililupy> if I want to deny bootp on a specific subnet in MAAS 2.1 I can use a DHCP snippet "deny bootp;"
<kiko> wililupy, I do think so
<wililupy> kiko, excellent. I"ll give it a try and report back.
<kiko> wililupy, do let us know if it doesn't work and what the resulting dhcpd.conf look like?
<wililupy> kiko: ack.
<mup> Bug #1643640 opened: same boot image listed multiple times <MAAS:New> <MAAS 2.1:New> <https://launchpad.net/bugs/1643640>
<mup> Bug #1643651 opened: MAAS UI takes a long time to load a node page <MAAS:New> <https://launchpad.net/bugs/1643651>
<jwitko> Hey All,  I'm wondering is there any way to disable the ability for server interfaces to be provisioned using "Auto Assign" ?
<kiko> jwitko, well, I think you can say "do not assign", right?
<jwitko> kiko, sorry ?
<kiko> jwitko, for a given interface?
<jwitko> Well, in general really.  Trying to disable it as a feature.
<jwitko> I have built some automation around MaaS and it is not the source of truth for IP addresses.  I don't use MaaS for VMs just bare metal, so it sometimes will try to assign an IP thats in use outside of MaaS
<jwitko> Can a static reservation over-ride a subnet IP reservation?
<jwitko> like if i disable a large block of IPs from being used does that just apply to dhcp and auto-assign or static as well ?
<jhova> Trying to use maas 2.x for the first time. When provisioning a server, after reboot of the initial provisioning, get booting local disk ... Warn: No MBR magic. treating disk as raw. Booting... and then nothing.
<jhova> Anyone dealt with this issue before?
<jhova> Also getting "/run/lvm/lvmetad.socket: connect failed: No such file or directory" in syslog during provisioning (xenial).
#maas 2016-11-22
<John> Hey guys, I'm having an issue with my MaaS
<Guest68615> Wondering if any of you can help me out a bit
<Guest68615> Is there anyone on here?
<roaksoax> jhova: shoot
<roaksoax> err
<roaksoax> sorry
<jhova> hey thanks for the response
<jhova> nm addressing different person
<roaksoax> jhova: ok, so I was reading your issue
<roaksoax> jhova: i dont fully understand
<roaksoax> jhova: so it installs but it doesn't boot ?
<roaksoax> jhova: what version of MAAS are you using (exact version)
<jhova> Yes, basically it seems like it's trying to use UEFI boot characteristics even though UEFI is disabled.
<jhova> 2.1.1+bzr5544-0ubuntu1~16.04.1
<jhova> menuentry 'Local' {
<jhova>     echo 'Booting local disk...'
<jhova>     search --set=root --file /efi/ubuntu/shimx64.efi
<jhova>     chainloader /efi/ubuntu/shimx64.efi
<jhova> }
<roaksoax> jhova: that's strange
<roaksoax> jhova: if that's the case, that means that the machine booted UEFI
<roaksoax> jhova: try to re-commission the machine
<roaksoax> jhova: and try to deploy again
<jhova> I have several times, I don't know what's happening.
<jhova> If you hit escape during pxe it loads fine
<jhova> All aspects of UEFI are disabled in the BIOS
<jhova> Do I need to completely delete to machine and re add? I've just been recommissioning the existing node.
<roaksoax> jhova: 1 sec,
<roaksoax> jhova: /win 2
<roaksoax> err
<roaksoax> jhova:  ok, so the way MAAS discovers the machine is booting is by looking at the request it makes to MAAs
<roaksoax> so if it make a request for EFI
<jhova> OK, should I grab that from the packets coming in?
<jhova> to see what it's requesting?
<roaksoax> jhova: so, the way the machine is told to EFI boot or pxelinux boot is via DHCP
<roaksoax> jhova: the machine sends a special code
<roaksoax> and the dhcp server identifies that from the dhcp packet
<roaksoax> jhova: and tells the machine to EFI boot or so on
<roaksoax> jhova: so my guess is your firmware trying to do that
<roaksoax> jhova: what if you enable EFI on your firmware ?
<jhova> After install it just boots to EFI shell
<jhova> http://pastebin.com/sV36sD5D
<jhova> roaksoax there is the DHCP request coming into maas
<jhova> http://pastebin.com/b8gRWGBU
<jhova> and the reply which shows the FNAME as pxelinux.0
<roaksoax> jhova: yeah, the option 93 is 00000
<roaksoax> which means pxelinux
<jhova> hmm wonder why grub is laying down a config for local boot to look for uefi shim
<roaksoax> jhova: i'd suggest you file a bug for now, and I'll raise it to someone tomorrow to try to figure out what could be going wrong
<roaksoax> but that's a very strange behavior
<roaksoax> since we test against efi and non-efi systems without any similar issue
<jhova> OK, sounds good. I saw this commit for an older version: https://code.launchpad.net/~allenap/maas/disable-uefi-temporarily/+merge/212150
<jhova> any way I can keep the shim from being installed and remove all uefi pieces?
<roaksoax> jhova: that branch is quite old, so it doesn't really apply
<roaksoax> jhova: so just so im clear. you machine PXE boots, grabs pxelinux.0, the machines is installed by MAAS
<roaksoax> then it reboots
<roaksoax> in PXE boots again but this time it is told to EFI boot ?
<roaksoax> jhova: or, after the reboot, the machine tries to boot directly from the disk ?
<jhova> That's what it appears like. Some machines complain about MBR magic and then stick at booting. Others go directly to booting local disk ... and drop to the prompt.
<roaksoax> jhova: i wonder if it is actually trying to boot from a different disk than the one where MAAS has installed ....
<roaksoax> jhova: that could be the reason
<jhova> Definitely could be. Where are the actual pxelinux configs on the maas server?
<jhova> Are the rendered from database entries?
<jhova> they*
<roaksoax> jhova: they are dynamically rendered. Maybe the BIOS has X disk as boot disk, but Y disk is the one being surfaced to the OS as /dev/sda, which would cause MAAS to install the mbr in /dev/sda but default
<roaksoax> jhova: but the BIOS is trying to boot from X
<roaksoax> jhova: you can go to MAAS UI, under the storage section on a machine in 'ready' state
<roaksoax> jhova: and you can select which disk is the "boot" disk
<roaksoax> so you might as well be able to say that /dev/sdb is the "boot" disk
<jhova> yeah, these servers have a SAS controller in them that might be the culprit
<roaksoax> that will cause maas to install MBR in /dev/sdb
<roaksoax> jhova: that could definitely be it
<jhova> I've tried messing around with all of the options, but can't disable it completely
<roaksoax> jhova: just try to select the right boot disk in the MAAS webui
<roaksoax> jhova: or set the right boot disk in the BIOS
<jhova> BIOS just says hard drive and not seeing a priority
<jhova> will keep investigating
<roaksoax> jhova: ok, so try to figure out which disk is the boot, and change the option in the MAAS webui
<roaksoax> jwitko: if something else is providing DHCP, you could either do: 1. static assign, and select the IP address you want to use instead of the suggested one or 2. DHCP
<jwitko> roaksoax, thanks for the response!  what I'm trying to avoid here is user error
<jwitko> I know how to literally avoid the issue by implementing a process around it
<jwitko> but i'm trying to guard rail people who don't pay attention
<Mynard> so I'm entering day 3 of trying to get openstack deployed on MAAS as a POC to replace the existing M$ HyperV "private cloud".
<Mynard> just doesn't seem like the components are all playing nicely together.
<Mynard> currently using 16.04 LTS, should I maybe go back to 14.04 LTS?  seems counter intuitive though ..
<mup> Bug #1643838 opened: ureadahead trying to read entire filesystem <landscape> <MAAS:New> <https://launchpad.net/bugs/1643838>
<mup> Bug #1643838 changed: ureadahead trying to read entire filesystem <landscape> <curtin:New> <MAAS:Invalid> <https://launchpad.net/bugs/1643838>
<apoz> Hi
<apoz> I'm a newbie with MAAS
<apoz> and I'm having some trouble to make it work
<apoz> (the rackd is asked for the pxelinux.0 image from a client, but it does literally nothing)
<apoz> how could I set debug logs in rackd?
<apoz> Is there anything I have to do for the rackd to download the boot images? (I installed everything in a single node with apt install maas)
<roaksoax> apoz: have you downloaded images
<roaksoax> apoz: i.e. logged into the UI and downloaded the images you need ?
<apoz> yes, I think so
<roaksoax> apoz:what do you mean "it does literally nothing" ?
<apoz> It just shows "pxelinux.0 requested from XXXXXXXX"
<apoz> and the client times out
<apoz> but it does not show any error in the log or anything
<apoz> just that line everytime the client reattempts
<apoz> (in the status is 'synced' of my images in the web CLI it means they are downloaded?)
<apoz> (the dot in the image for 16.04 is green, so I'm assuming images are OK)
<apoz> is there any way to boot the rackd with debug logs so I can investigate further?
<jhegge> sweet
<apoz> ?
<mup> Bug #1643939 opened: UI shows custom boot source selected and incorrect boot source selections but CI shows seemingly valid resources <MAAS:New> <https://launchpad.net/bugs/1643939>
<jhova> roaksoax got my issue worked out, thanks
<jhova> Is there a python client available that supports maas v2 api?
<jhova> or a client in any language would work
<roaksoax> jhova: there is theolder client library, python-maas-client
<roaksoax> jhova: but we are working on a new one
<jhova> yeah, says it only supports v1
<jhova> ok, thanks
<deej> Hey gents, I'm running 2.1 and hitting some problems using the CLI to get nodes with a specific tag
<deej> It keeps telling me I'm trying to using 1.0 API which, as far as I can tell, is not the case
<deej> $ maas-cli maas-root tag nodes os-cs
<deej> The 1.0 API is no longer available. Please use API version 2.0.
<deej> Any advice?
<kiko> deej, it's a bug likely
<mup> Bug #1516065 opened: [2.2, 2.1, 1.9] Unable to power manage IPMI if BMC does not support changing boot order <uosci> <MAAS:In Progress by newell-jensen> <MAAS
<mup> 1.9:Fix Released by newell-jensen> <MAAS 2.1:In Progress by newell-jensen> <MAAS trunk:In Progress by newell-jensen> <https://launchpad.net/bugs/1516065>
<deej> kiko: So I'm assuming my best bet is to access the API directly?
<kiko> deej, well.. roaksoax, blake_r: ^^
<roaksoax> deej: use 'maas' not maas-cli
<roaksoax> deej: and maybe you have logged into 1.0 api
<deej> roaksoax: They return the same
<roaksoax> maas login admin http://192.168.10.27:5240/MAAS/api/2.0/
<kiko> uhh
<kiko> what is maas-cli?
<roaksoax> kiko: that's the package name. maas-cli forwards to maas for backward compat
<roaksoax> deej: maas --help
<kiko> gotcha
<roaksoax> deej: you shoudl see something like:
<roaksoax>     changepassword
<roaksoax>                   Change a MAAS user's password.
<roaksoax>     admin         Interact with http://192.168.10.27:5240/MAAS/api/2.0/
<deej> roaksoax: Ah!
<deej> I had a leftover .maascli.db from maas 1.9
<deej> Nuking that and re-logging in did the trick, ta
<mup> Bug #1644014 opened: maas 2.1 CLI does not allow listing of nodes with a specific tag <MAAS:New> <https://launchpad.net/bugs/1644014>
<deej> That was me, Ill close
<kiko> roaksoax, the .maascli.db file being left over and not warned is a bug though, is it not?
<kiko> deej, ^^
<zeestrat> roaksoax:, what's the status on some kind of backup/restore utility or
<zeestrat> * or some docs on that.
<deej> kiko: Interesting point, I'm not sure you can clean that up per se, but the maas2 CLI could certainly warn if it found one
<deej> Presumably anyway
<jwitko> hi all, I just accidentally upgraded from maas 2.0 to maas 2.1
<jwitko> is there any way to reverse this process?
<jwitko> the database seems to be in-tact
<jwitko> I have an HA setup, will the failover process still work after an upgrade>?
<jwitko> roaksoax, not sure if you're around but could really use your help
<mup> Bug #1644014 changed: maas 2.1 CLI does not allow listing of nodes with a specific tag <MAAS:Invalid> <https://launchpad.net/bugs/1644014>
<roaksoax> jwitko: not sure I follow. you have a MAAS in active/passive
<roaksoax> jwitko: and you upgraded 1t to 2.1
<roaksoax> but not the other ?
<jwitko> yes
<jwitko> that is correct
<jwitko> roaksoax I'm looking for a way to roll back
<jwitko> and if i can't then at least to fail-back
<jwitko> it appears my curtin file is not happy in 2.1 either
<jwitko> "main_archive_hostname" is no longer defined?
<roaksoax> jwitko: what does your curtin file look like ?
<jwitko> It had some apt sections that were using variables from 2.0.0 that apparently no longer work in 2.1.1
<jwitko> i removed it and will deal with apt sources after the fact
<jwitko> roaksoax, I'd prefer at this point to move forward on 2.1.1 but I'm having an issue with the API
<jwitko> POST queries are returning "TypeError: 'Machine' not iterable"
<jwitko> http://paste.ubuntu.com/23519335/
<jwitko> roaksoax, here is another issue in the curtin file regarding enabling HTTP proxy if its enabled within maas  http://paste.ubuntu.com/23519338/
<jwitko> that worked in 2.0.0
<roaksoax> jwitko: ok, i jnow what that is
<roaksoax> jwitko: id suggest you remove that whole snippet
<jwitko> which one?  the API or the Apt proxy stuff?
<roaksoax> jwitko: it should just work without
<jwitko> ok  I've removed it
<jwitko> any idea on those API errors>?
<jwitko> I am getting them left and right
<roaksoax> jwitko: no. do you have the call you used that showed those erros
<jwitko> getting that now
<jwitko> but its just standard POST calls
<jwitko> roaksoax, here http://paste.ubuntu.com/23519387/
<jwitko> and here is another one that fails
<jwitko> http://paste.ubuntu.com/23519388/
<jwitko> here is how the URL is generated http://paste.ubuntu.com/23519392/
<jwitko> on about 60-70% of requests I receive the error
<roaksoax> jwitko: strge,
<roaksoax> ltrager: ^^ any ideas?
<ltrager> roaksoax: hmm not sure, trying to reproduce
<ltrager> jwitko: I think part of the problem may be you're running in HA with 2.0 and 2.1. 2.1 brought in some data migrations which 2.0 may not be able to handle
<jwitko> ltrager, we were getting the error in 2.0.0, the upgrade was an attempt to fix it
<jwitko> but i didn't mean to go to 2.1, just to the latest 2.0.0
<jwitko> but that being said, it is the same exact error/message from 2.0.0
<ltrager> jwitko: did any region get upgraded to 2.1?
<jwitko> ltrager, not sure what you mean?
<jwitko> one region and one rack controller were upgraded
<jwitko> they live on the same host
<jwitko> the other host, which has a region and rack controller as well, were not upgrade
<ltrager> jwitko: as part of the upgrade process MAAS runs database migrations. When running in HA mode all regions access the same database. So if one region was upgraded to 2.1 the database is now using a 2.1 format
<ltrager> jwitko: that could cause problems if an older version of MAAS is trying to connect
<ltrager> jwitko: all region and rack controllers in your system should be at the same version
<jwitko> alright
<jwitko> let me upgrade the other
<ltrager> roaksoax, jwitko: btw I hacked together a script to list machines 100 times and I'm not seeing any errors
<jwitko> ok 2nd rack and region controller updated
<jwitko> both have status green
<nate_> Hello! Could I get a hand configuring Juju for MAAS behind a corporate proxy? There seems to be very limited documentation available for the latest versions.
#maas 2016-11-23
<pmatulis> nate_, ask and see
<nate_> I've been trying to follow the instructions here: https://jujucharms.com/docs/stable/getting-started
<nate_> But even juju bootstrap localhost lxd-test fails due to the proxy. I can't find any documentation for setting juju to use a proxy, thus I also am unable to deploy to any maas nodes.
<vmorris> nate_: i have some info on this
<nate_> Excellent! I would love to hear it
<vmorris> nate_: when you bootstrap your juju controller, use --config=config.yaml where config.yaml contains something like...
<vmorris> http://paste.ubuntu.com/23519637/
<vmorris> then all of your juju created machines will pick up the proxy environment variables
<pmatulis> '--config http-proxy' is prolly what you want
<nate_> Awesome! Thank you for that. Yes, I need http-proxy, but I need everything listed in that yaml file. I will test this out and let you know how that goes. Is there a default place I can put that to make Juju automatically use those?
<pmatulis> i don't think so
<vmorris> nate_ you can set 'juju model-defaults' though you've gotta have the controller bootstrapped... so you can do it during bootstrap or after
<vmorris> but i agree with pmatulis
<nate_> So before I've done anything I just need to manually enter it. Got it
<vmorris> nate_ actually i'm curious now, you might be able to set model-defaults to something and not have to set the config every time you bootstrap
<vmorris> seems to be the purpose of that option
<nate_> I tried that once before, but it wouldn't let me do it without a model created
<vmorris> 'model-config' or 'model-defaults' ?
<vmorris> because 'model-defaults' seems to apply to a cloud
<vmorris> ah 2nd look, i think you're right about that..
<nate_> I can only do that once I've registered a controller, but I can't register a controller without setting the proxy
<vmorris> yep, you'll have to do what I do I suppose then.. pass it in with the config at bootstrap
<nate_> vmorris unfortunately it didn't work. I still get the error "failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: Get https://cloud-images.ubuntu.../index.json: lookup cloud-images.ubuntu.com on... no such host
<nate_> It appears it doesn't like my corporate DNS? I can't really tell if it's the DNS or the proxy that's the problem.
<vmorris> nate_ was this on localhost lxd or the maas cluster?
<nate_> This was localhost lxd
<vmorris> do you have connectivity to cloud-images.ubuntu.com from there?
<vmorris> or do you need to pass through the proxy as well?
<vmorris> like, can you run "lxc launch ubuntu-daily:xenial" ?
<nate_> Using curl I can access cloud-images.ubuntu.com from the maas server (which is localhost), and it's almost certainly using the corporate proxy from my environment variables to do that
<nate_> But lxc launch ubuntu-daily:xenial failed
<nate_> Same no such host error
<vmorris> can you run 'lxc profile list'
<pmatulis> nate_, maybe DNS is broken. try 'host cloud-images.ubuntu.com'
<nate_> NXDOMAIN not found
<pmatulis> there you go
<nate_> But why would it work with curl?
<pmatulis> maybe it's sucking in a variable somehow
<vmorris> http vs https?
<nate_> I tested curl with both http and https and they both work fine
<vmorris> ah nah that wouldn't cause the dns issue
<nate_> So DNS is broken in some cases, but working in others
<vmorris> in my setup here, i had to create my own dns forwarder too :/
<pmatulis> nate_, if host command gives you brokenness then you really need to debug that. try pointing to what's in /etc/resolv.conf
<pmatulis> host <name> <resolv.conf-IP>
<vmorris> but that was because maas-controller needed it, lxd localhost shouldn't be an issue
<nate_> By the way, the maas cluster is fully provisioned, and maas itself isn't having any dns issues
<nate_> Using the DNS in /etc/resolv.conf, host still returns not found
<nate_> Yet it's the same IP that was used by curl for DNS
<pmatulis> try another name? other than cloud-....?
<vmorris> curl --dns-ipv4-addr <resolv.conf-IP> cloud-images.ubuntu.com
<vmorris> just to confirm that
<nate_> curl: (4) A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision.
<nate_> It appears I don't have that feature
<vmorris> bummer
<vmorris> host google.com ?
<nate_> Not found
<nate_> But curl google.com works
<nate_> maas also has no DNS issues running on this server, and I know it's using the same DNS IP that I am
<vmorris> dig google.com ?
<nate_> It made it
<vmorris> i'll guess that 'dig cloud-images.ubuntu.com' also works --
<nate_> ...actually, no, neither worked, sorry
<vmorris> aha
<nate_> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> cloud-images.ubuntu.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10183 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
<nate_> ANSWER: 0 means no response, right?
<vmorris> correct
<nate_> The AUTHORITY section lists the closest corporate DNS to the proxy
<nate_> And an exchange server
<vmorris> at the bottom, you should see SERVER: -- does this match what you have in /etc/resolv.conf?
<vmorris> i can't imagine why it wouldn't..
<nate_> Yes it does.
<nate_> I just tested this on another ubuntu machine and got the same results. Curl is successful, but host can't find anything
<nate_> It appears this is the case for all Linux boxes on my intranet.
<vmorris> cloud-images.ubuntu.com is 91.189.88.141... can you try, just for kicks, 'curl http://91.189.88.141' ?
<nate_> Yes, that works, same results as curl cloud-images.ubuntu.com
<vmorris> ah right
<vmorris> host 91.189.88.141 ?
<vmorris> it's possible that your corporate DNS is not setup for forwarding requests to ubuntu.com :/
<nate_> Host 141.88.189.91.in-addr.arpa. not found: 3(NXDOMAIN)
<vmorris> I should say, forwarding lookup requests to another server for "ubuntu.com"
<nate_> But then why would curl work fine? I can also access it in the browser with no issues, and maas successfully downloaded images from there as well
<vmorris> yeah, it's a strange problem
<vmorris> does wget work?
<pmatulis> nate_, try tcpdump on UDP 53 to see what nameserver curl is using. how does it compare to that in resolv.conf
<nate_> Yes, wget works great.
<nate_> tcpdump defaults to openstack0 now... That's odd
<vmorris> yeah, dump udp 53
<nate_> Alright. Lots of stuff coming through.
<nate_> NXDomain does use the same DNS as resolv.conf
<vmorris> see if it's different when you run curl vs host
<nate_> host uses A
<nate_> I don't actually see anything in there from curl
<vmorris> ah yeah doesn't curl cache dns?
<vmorris> http://stackoverflow.com/questions/25672005/curl-how-to-set-up-ttl-for-dns-cache-how-to-clear-the-curl-cache
<vmorris> defaults to 60 seconds? i think you'd have noticed a problem by now
<nate_> Yeah... Though it's odd that curl doesn't show up in my dump
<nate_> The dns is always getting asked for ntp.ubuntu.com.maas though
<nate_> And ntp.ubuntu.com as well. So I assume it doesn't have trouble with ubuntu.com
<blahdeblah> I thought the resolver wasn't supposed to use the search domain for anything containing dots
<vmorris> pretty strange nate_ ... best of luck sorting it out :/
<nate_> Thank you!
<pmatulis> nate_, try strace on curl to see what it's doing (reading files, etc)
<nate_> pmatulis the output is enormous
<nate_> I did a search for my DNS IP
<nate_> I found sin_addr=inet_addr("my.dns.ip.addr")},16) = 0
<nate_> Lots of other connections made to that IP in strace
<pmatulis> nate_, yet tcpdump does not concur with that right? do you have multiple network interfaces? maybe you applied tcpdump on the wrong one
<nate_> One network interface that actually goes to the internet, so the success of curl indicates it's using the right one
<nate_> And the dump didn't have the domain name in it when I ran curl, so I'm not sure
<pmatulis> try a dump with the failing host command. where does it want to go?
<pmatulis> and what, exactly, is the full contents of resolv.conf ?
<pmatulis> to assist with troubleshooting, i'm quite certain that the host command uses neither /etc/nsswitch.conf nor /etc/hosts
<bala> hey
<bala> can i use maas to provision ubuntu desktop version on bare metal ?
<roaksoax> bala: you could install extra packages to install ubuntu destop
<roaksoax> bala: or you can use lp:curtinator to create a desktop image
<bala> thank you roaksoax
<bala> can you share any link which has information installing additional packages for desktop
<mup> Bug #1644071 opened: [SRU] MAAS 2.1.2 <maas (Ubuntu):New> <maas (Ubuntu Xenial):New> <maas (Ubuntu Yakkety):New> <https://launchpad.net/bugs/1644071>
<pmatulis> 'sudo apt install ubuntu-desktop' ? seems that's what worked years ago anyway bala
<roaksoax> bala: you could modify /etc/maas/preseeds/curtin_userdata to include something like: http://paste.ubuntu.com/23520222/
<mup> Bug #1644219 opened: MAAS web ui does not display bond parameters <MAAS:New> <https://launchpad.net/bugs/1644219>
<mup> Bug #1644229 opened: MAAS 2.1.1 - Failed to deploy CentOS7 <MAAS:New> <https://launchpad.net/bugs/1644229>
<mup> Bug # changed: 1609975, 1613862, 1621635, 1629430
<mup> Bug #1640298 changed: multiple subnets dhcp shared-network does not work with dhcp-relay <MAAS:New> <https://launchpad.net/bugs/1640298>
<mup> Bug #1644316 opened: maas ui rejects tags containing "." w/o explanation <error-surface> <MAAS:Triaged> <https://launchpad.net/bugs/1644316>
<mup> Bug #1644345 opened: The region should verify database migrations on start <MAAS:Triaged> <https://launchpad.net/bugs/1644345>
<junaidali> i have a fresh maas (2.1.2) setup, getting a bunch of errors on commissiong "maasserver.preseed.TemplateNotFoundError: commissioning". Any idea, what might be the issue here?
<junaidali> this error too "maasserver.preseed.TemplateNotFoundError: enlist"
<junaidali> there aren't any files in /etc/preseeds directory. I think i should try re-installing maas
<pmatulis> junaidali, interesting. in 2.1 commissioning templates were removed from their old location
<pmatulis> roaksoax, ^^^ related to our previous convo?
<junaidali> pmatulis: where can I find the template file?
<junaidali> files*
<pmatulis> junaidali, i think the best bet is to open a bug. i don't know enough to guide you
<pmatulis> https://bugs.launchpad.net/maas/+filebug
<pmatulis> remember to include logs (/var/log/maas/{rackd,regiond,maas}.log)
<junaidali> thanks pmatulis , opening a bug..
<pmatulis> welcome
<mup> Bug #1644354 opened: Unable to enlist or commission new nodes with template related errors <MAAS:New> <https://launchpad.net/bugs/1644354>
#maas 2016-11-24
<mup> Bug # changed: 1516065, 1640300, 1642996, 1643057
<kiko> good morning
<mup> Bug #1644354 changed: Unable to enlist or commission new nodes with template related errors <MAAS:Invalid> <https://launchpad.net/bugs/1644354>
#maas 2016-11-25
<slevchenko_> Hi everyone, I need to perform Ubuntu installation with MaaS. The prolem is that Node has like 25 disks which confuses installator, it expects for an answer where to install bootloader, so installation stucks. My question is following, how I can tell MaaS to install loader on certain drive, for exmple '/dev/sda' ?
<brendand> slevchenko_, which version are you using?
<slevchenko_> 2.1
<brendand> slevchenko_, ok. did the machine commission?
<brendand> i.e in Ready state
<slevchenko_> Yup, nodes were commisioned successfully
<brendand> slevchenko_, ok
<brendand> give me a minute while i check something
<slevchenko_> ok no problem
<brendand> slevchenko_, under the machine 'Used disks and partitions, is anything selected?'
<slevchenko_> No
<brendand> slevchenko_, no radio buttons under the 'boot' column?
<slevchenko_> There's:
<slevchenko_> Available disks and partitions
<slevchenko_> and radio-button next to each of 25 disks
<slevchenko_> radio-buttons in boot column
<brendand> slevchenko_, but none of the radio buttons is selected?
<slevchenko_> Yes
<brendand> slevchenko_, can you try selecting one and deploying again?
<brendand> really it should select one by default but we can try and figure out why it didn't after we make sure this works
<slevchenko_> Before I'll try do you know is it possible to do through a cli ?
<brendand> slevchenko_, yes
<slevchenko_> Asking because deploying 103 machines through UI would be kinda painful
<slevchenko_> oh then I'll try, thx
<brendand> slevchenko_, indeed :)
<slevchenko_> Thank you very much Brendan
<brendand> slevchenko_, let me know if it works, i might have an alternative suggestion if it doesn't
<slevchenko_> Sure, thanks again
<slevchenko_> Also Brandan, MaaS has hardcoded commisioning timeout in 20 minutes, and servers have no proper DNS yet, so sudoing takes like eternity :(
<slevchenko_> Is it possible to workaround it like this?
<slevchenko_> early_commands:
<slevchenko_>   maas: [echo, '127.0.1.1 {{node.hostname}}' >> '/etc/hosts']
<slevchenko_> This block will go to curtin installer
<slevchenko_> *preseed
<brendand> slevchenko_, why 127.0.1.1?
<slevchenko_> just a placeholder for a sudo to resolve host faster
<slevchenko_> it can be 127.0.0.1
<mup> Bug #1644856 opened: Issue with changing device naming of boot disk between commissioning and deployment <MAAS:New> <https://launchpad.net/bugs/1644856>
<Guest78801> Hi
<Guest78801> Can any body have idea about MAAS 2.0 on Ubuntu 16.04
<Guest78801> i have installed and all machines are in ready status
<Guest78801> now i would like to proceed further for openstack deployment
<Guest78801> what are the next steps, seeking guidance for exact steps???
<pmatulis> Guest78801, have you considered using Juju to manage the services (e.g. openstack) that will run on the MAAS nodes?
<pmatulis> (see #juju on freenode)
<Guest78801> Yes but i assume as per documentation by installing openstack juju is implicitly installed
<Guest78801> is this so???
<pmatulis> Guest78801, link to documentation that says that?
<Guest78801> I dont have exactly the link but i read during searching
<pmatulis> Guest78801, ok, so, no, openstack can be installed without juju
<Guest78801> ok can u pls guide me after MAAS installation and machines readiness what are next steps
<pmatulis> Guest78801, you will need to be willing to invest time into studying this stuff but for a possible quick win you can try http://conjure-up.io/
<Guest78801> ok thanks
<mup> Bug #1644920 opened: Image selection unclear <docteam> <MAAS:New> <https://launchpad.net/bugs/1644920>
<dakj> Hello, someone know how setting the power type of MAAS using VMware fusion?
<dakj> Anyone can help me?
<jhegge> Fusion won't work with MAAS, doesn't have the SSL port used to configure vmware power type
<dakj> @jhegge MAAS can work only with VMware Workstation and not with Fusion, is it right?
<jhegge> possibly Workstation, but more like ESXi or vSphere
#maas 2016-11-26
<mup> Bug #1604393 changed: MAAS is not listing the storage disks <MAAS:Expired> <MAAS 1.9:Expired> <MAAS 2.0:Expired> <MAAS trunk:Expired> <https://launchpad.net/bugs/1604393>
#maas 2016-11-27
<mup> Bug #1645057 opened: [web UI] erasure options during Release do not reflect chosen default <docteam> <MAAS:New> <https://launchpad.net/bugs/1645057>
<mup> Bug #1645067 opened: Disk erasure doesn't work, with KVM-backed node at least <docteam> <MAAS:New> <https://launchpad.net/bugs/1645067>
<mup> Bug #1645119 opened: Nodes fails with cloud init errors <MAAS:Incomplete> <https://launchpad.net/bugs/1645119>
<mup> Bug #1645119 changed: Nodes fails with cloud init errors <MAAS:Incomplete> <https://launchpad.net/bugs/1645119>
<mup> Bug #1645119 opened: Nodes fails with cloud init errors <MAAS:Incomplete> <https://launchpad.net/bugs/1645119>
<john75077> evening all
<john75077> i went to the checklist on maas.io - is there any special requirements needed to perform a 'rack install' ?
<john75077> so from what i am reading i can perform a MAAS install and then use LXD and launch JUJU to perform the Openstack Install?
#maas 2017-11-20
<mup> Bug #1709095 changed: Commissioning fails when cloud init can't find a data source <MAAS:Expired> <https://launchpad.net/bugs/1709095>
<mup> Bug #1709095 opened: Commissioning fails when cloud init can't find a data source <MAAS:Expired> <https://launchpad.net/bugs/1709095>
<mup> Bug #1709095 changed: Commissioning fails when cloud init can't find a data source <MAAS:Expired> <https://launchpad.net/bugs/1709095>
<mup> Bug #1733285 opened: Unable to create pod with MAAS 2.3-rc2 on 17.10 <s390x> <MAAS:New> <https://launchpad.net/bugs/1733285>
<mup> Bug #1733285 changed: Unable to create pod with MAAS 2.3-rc2 on 17.10 <s390x> <MAAS:New> <https://launchpad.net/bugs/1733285>
<mup> Bug #1733285 opened: Unable to create pod with MAAS 2.3-rc2 on 17.10 <s390x> <MAAS:New> <https://launchpad.net/bugs/1733285>
<xygnal> roaksoax: is the centos6 images in the maas repo currently broken?  curtain fails trying to set grub root on our device.
<xygnal> have a traceback but it doenst explain a whole lot
<xygnal> it need sto set root to sdm, as the RAID1 is showing as final disk not first disk (We have jbods too)
<roaksoax> xygnal: not to my knowledge. we've not made any changes other than getting the latest centos6 images
<roaksoax> xygnal: also, we dont support efi on centos6 if that's what you were using
<roaksoax> since at the time of enablement,what was needed for efi wasn't available in centos6 iirc
<xygnal> roaksoax: we are running BIOS only on all of our stuff.  I was just asking about EFI in case it might helkp our boot situation.
<xygnal> roaksoax: we are using th strait vanilla image you host for centos7
<xygnal> er centos6*
<xygnal> typo
<xygnal> and it fails with that
<xygnal> its not installing on /dev/sda which is the only reason I can imagine its having a problem
<[Kid]> is there a way to use hostnames with juju and MAAS to deploy certain machine numbers to certain nodes by hostname?
<xygnal> it shows root and boot selection for /dev/sdm but it fails with that
<[Kid]> hopefully that makes sense
<xygnal> roaksoax: i am booting  centos6 iso now to see what order the disks select in. could be taht /dev/sdm is not the same once in the OS?
<roaksoax> xygnal: for centos maas picks the first disk the os finds and that's where it installs
<xygnal> hm but no that should still be in the ubuntu install image at that point
<xygnal> roaksoax: we have code in our curtin preseed file that uses the boot device
<xygnal> roaksoax: you helped us to code that actually to work around it
<roaksoax> [Kid]: I think juju /may/ have a way to use a constraints based on machine name. It used to have, I haven't used juju in a while
<xygnal> but it seems to only be working in centos7
<[Kid]> according to the guys in #juju tags are the only way
<roaksoax> xygnal: strange. Both centos6/7 images process it exactly the same
<[Kid]> not a huge deal
<roaksoax> xygnal: the only thing I could imagine is a different version of software inside centos may be the cause ?
<roaksoax> xygnal: can you file a bug ?
<xygnal> roaksoax: hold on.  I just disccovered he is using centos not custom, and our curtin code is only in custom
<xygnal> so need to look at this first and make sure its being used correctly
<roaksoax> xygnal: ack, ah that's it then
<roaksoax> xygnal: it needs to be custom
<xygnal> roaksoax: just tried my custom stuff in the centos file, still fails.  I have debug output for you.
<xygnal> roaksoax: pasted in private chat
<xygnal> roaksoax: does ubuntu curtin not support the same options as custom?
<xygnal> er
<xygnal> sorry
<xygnal> why do i keep using ubuntu?
<xygnal> brain not working
<xygnal> Can curtin_userdata_centos  support the same options as curtin_userdata_custom
<xygnal> i never used the ubuntu image - just brain tired. i meant the centos image vs the custom image. we have been using centos and centos preseed file to try to replicat the same results
<xygnal> roaksoax: export the image, imported it as custom image
<xygnal> tried again
<xygnal> same failure, same error
<roaksoax> xygnal: images under "centos" are not sent the storage config, so curtin doesn't do the partition
<roaksoax> xygnal: custom images do get it
<roaksoax> xygnal: that's probably why things fail
<xygnal> roaksoax: well i just did custom and it failed exactly the same way
<xygnal> so thats not it
<xygnal> roaksoax: do you want to see the full trace output on that like i did for the previous one?
<xygnal> at this point im considering writing a manual endpoint to turn jbod on/off before/after deployment manually
<xygnal> because its the only way MAAS can cope with centos6 on our hardware
<roaksoax> xygnal: does centos6 work with jbods ?
<roaksoax> with your jbods ?
<correct> if I don't get the paid version of MAAS, this means I can't provision Windows systems?
<kiko> correct, you can but you need to roll your own images, essentially
<kiko> the image build service is commercial
<kiko> so perhaps s/correct/partially correct/
<rick_h> howdy folks, I've got a long running maas on a single laptop that I've upgraded today to rc-2 and I'm getting the "One rack controller is not yet connected to the region. Visit the rack controllers page for more information."
<rick_h> I've restarted the machine. As it's a single laptop it's both region/rack controller and I'm not up on what the new UX is trying to tell me here. Any hints on what's been changing?
<rick_h> checking logs: https://pastebin.canonical.com/203665/
<roaksoax> rick_h: the rack controller cannot connect to the region for some reason
<roaksoax> rick_h: pb both regiond.log and rackd.log
<rick_h> k, checking
<correct> kiko: lol.
<rick_h> roaksoax: oh hmm, it's trying to connect ipv6
<correct> kiko: I'm rollin'em already with cobbler.  Excited to test out MAAS.
<correct> kiko: so.. when say roll my own, typycally, I have cobbler use ghost to deploy the image... with MAAS does it work in a similar fashion?
<rick_h> roaksoax: so I've got the 10.0.0.1 in both rackd and regiond.conf files. Logs show: Region not available: User timeout caused connection failure. (While requesting RPC info at b'http://[::ffff:10.0.0.1]/MAAS/rpc/').
<correct> as I am using a ghost image, does MAAS offer some other ways of deploying my custom image?
<rick_h> roaksoax: is it pulling from something other than the maas_url in each?
<roaksoax> rick_h: is maas_url pointing to 10.0.0.1/MAAS or 10.0.0.1:5240/MAAS ?
<rick_h> roaksoax: in the rackd it's sans-port, in the regiond it's with port
<roaksoax> rick_h: use :5240, maas opens port on 5240, not on other ports
<kiko> correct, no, MAAS uses curtin -- see https://readthedocs.org/projects/curtin/
<kiko> correct, sorry, I'm OTP so very slow today
<kiko> shucks
<kiko> correct, http://curtin.readthedocs.io/en/latest/ is what I really meant
<xygnal> darn
<xygnal> TJ's suspicion dint pan out
<xygnal> after extracting a failed/stalled boot
<xygnal> the checksums on the initrd and kernel match :(
<xygnal> why is it stalling?!
<correct> kiko,.. while installing MAAS, I got an error regarding psql
<correct> I'm gussing server have not started
<xygnal> you are are correct
<correct> It appears there is a problem with the bootstrap install?
<xygnal> you are are correct
<correct> xygnal: umm... is there a post installation script for the db?
<xygnal> i'm not answering your questions i'm just saying your name ;)
<correct> lol
<xygnal> i dont know what your problem is, i am in here as i have my own problems
<correct> basically..I'm installing MAAS.  I am at a section that configures postgressdb for MAAS
<correct> it erors out.
<correct> as it can't connect to DB
<roaksoax> rick_h: /win 5
<roaksoax> err
<rick_h> wheee
<correct> I get this https://snag.gy/osnOIl.jpg
<rick_h> roaksoax: hmm, seems because it's long running I'm having fun with old e/n/i vs new interface names/etc and that's causing me to have fun. Thanks for helping me poke at the logs/etc
<correct> lol.. this is not working.  i'm not sure what to do here.
<correct> This question may not have been addressed: https://askubuntu.com/questions/965303/unable-to-install-maas-directly-using-dvd
<xygnal> no fun -o
<xygnal> =p
<heyya> If I skip the DB setup.. is can't it be configured later?
<heyya> or do I need to do a layered install?
<heyya> *can the postgre db be configured after ?  if so, how so?
<xygnal> if i had to take a guess heyya i would say, it needs to populate the database during install
<heyya> xygnal, yeah.. but this install has been mostly unattended
<xygnal> possible to spin up a database in advance, even if you dont keep it?
<heyya> I saw a posting mention that I need to layer the install
<heyya> like install ubuntu server with ssh, then maas controller, etc
<heyya> ubuntu server with postgresql
<heyya> I need to look at installer script
<heyya> the installer is searching for a DB that does not exist
<xygnal> TJ-: wireshark can decode the TFTP files! still trying to get a client-end capture though
<heyya> crap.. just don't wanna do this again
<xygnal> i thoguht it spun up the db for you
<heyya> xygnal: that's what I thought, did you see the posting ? ---> https://askubuntu.com/questions/965303/unable-to-install-maas-directly-using-dvd
<TJ-> xygnal: you still at that!?
<xygnal> TJ-: well that was friday so i only just picked it up agian today.
<xygnal> TJ-: I was able to confirm the whole TFTP image goes throguh, but without the client capture i can't verify the sum
<TJ-> xygnal: seems like a month ago to me
<xygnal> TJ-: it's new infra so we dont have spans setup yet. tough spot.
<TJ-> xygnal: right; did you try with bootstrapping via iPXE
<xygnal> TJ-: no, woudln't help us since MAAS doesn support it yet
<xygnal> or are you implkying ipxe client can tell me if the checksum was good?
<xygnal> wouldn't it still be force to use old PXE protocol because of server?
<xygnal> you wanted me to spin up a whole second pxe server to test in there and that seems a bit overkill
<TJ-> xygnal: As I said last week - if you booted the hardware from an iPXE CD-ROM/USB, so it then tries to do a PXE boot, and it works all 50 times (or however many you test for), it'd indicate the problem could be in the system firmware's PXE implementation
<TJ-> xygnal: but if 1 or more of those tests fail you know there's an intermittent network issue
<xygnal> TJ-: only happens in networks with switches that have ACI
<xygnal> TJ-: same hardware. so we suspect not firmware.
<heyya> isn't that ACL ?
<xygnal> nope
<TJ-> xygnal: So you're sure the issue is the network?
<xygnal> ACI. cisco switch technology.
<xygnal> TJ-: 99% certain, but i just found a cisco ACI bug release saying that it causes UDP/TFTP traffic to fail
<xygnal> so crossing my fingers we aren't at taht ACI patch level
<TJ-> xygnal: so, even if you prove a packet goes astray/is corrupted, you still won't know why or where it happens
<TJ-> xygnal: oh really? I bet you are!
<TJ-> xygnal: what's the bug reference?
<heyya> Do you put all the MAAS components on one node?
<TJ-> xygnal: 'fail' or 'drop packets' - the former suggests the connection fails.
<xygnal> CSCaz88813
<xygnal> uz*
<xygnal> not az
<xygnal> "bridge packets dropped on network"
<xygnal> find it?
<TJ-> xygnal: that does look like it, but if it is down to a specific byte sequence, you'd expect the boot to fail the same way every time, surely? (Because its always the same data and presumably packet headers ) - Or does the server get a different IP each time/some times ?
<xygnal> xygnal: yes it does get different IPs.  There are commissions and deployments.
<xygnal> they fail so re-trying grabs a new IP
<xygnal> the commissions at the least
<TJ-> xygnal: if it is that bug you can test it easily. Get the server booted successfully one-time, then run a UDP stream to it and compare what's sent to what's received. That way you have full control on the server-side
<TJ-> xygnal: in other words; no need to try debugging TFTP, just debug a continuous UDP stream
<TJ-> xygnal: you can use netcat (nc) either side, e.g: "cat /some/large/text/file | nc -4u server $testport" ->>> "nc -4ul $testport | tee /tmp/received/file"
<xygnal> TJ-: so a netcat test?
<xygnal> damn you internet
<TJ-> xygnal: I think we both lost connection! did you see my netcat example?
<TJ-> 19:51:36    TJ- | xygnal: you can use netcat (nc) either side, e.g: "cat /some/large/text/file | nc -4u server $testport" ->>> "nc -4ul $testport | tee /tmp/received/file"
<roaksoax> heyya: not from the cd. The bug is fixed but dind't make it into the CD
<roaksoax> heyya: also, you can install directly after ytou install from cd
<xygnal> TJ-: we are at 2.3 fw level so, oh well
<xygnal> can't be the cisco bug
<TJ-> xygnal: no harm doing the UDP streaming test though.
<xygnal> oh yes I have to in order to prove the network that its not my problem
<xygnal> thats next
<mup> Bug #1733411 opened: MAAS should create static leases for ephemeral boots when possible <MAAS:Triaged> <https://launchpad.net/bugs/1733411>
<mup> Bug #1733420 opened: virsh power type check error <MAAS:Incomplete> <https://launchpad.net/bugs/1733420>
<heyya> roaksoax: I just did a fresh install of ubuntu server with dns,postgres and ssh.  Server is up
<heyya> roaksoax: apt-cache has the package, but I was reading I should add ppa:mass/stable
<heyya> anyway.. will install use the ppa
<roaksoax> heyya: the ppa wont gfive you anything different from the archives
<roaksoax> heyya: unless you want something newer
<roaksoax> heyya: maas 2.3 goes out officially tomorrow and 2.2 will be replaced in PPA
<roaksoax> so if you want the latest ppa is probably the best
<heyya> sweet.. did it.. FYI MAAS is SOOOO nice
<roaksoax> glad to hear that :)
<heyya> very mature from what I can see
<heyya> I have dhcp funning already.. I guess I can configure my dhcp to use the pxe from MAAS
<roaksoax> yu can, yes
<heyya> not sure how I want to set it up yet.  With MAAS, I'll have 2 pxe servers running.
<heyya> I guess I'll have to disable the other pxe while I'm testing
<heyya> or restict it.
<heyya> hmm.. ok.. I'll lock it down to a network
<heyya> What are DHCP snippets in Maas?  does that indicate the network for serving dhcp?
<heyya> When i dig @MAAS i get WARNING: recursion requested but not available
<mup> Bug #1733442 opened: Cannot delete Virsh Pod <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1733442>
<mup> Bug #1733442 changed: Cannot delete Virsh Pod <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1733442>
#maas 2017-11-21
<mup> Bug #1733442 opened: Cannot delete Virsh Pod <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1733442>
<mup> Bug #1733600 opened: Custom images removed from Web UI still show up as an option during deploy in Web UI <MAAS:New> <https://launchpad.net/bugs/1733600>
<mup> Bug #1733615 opened: [SRU] MAAS 2.3.0 <maas (Ubuntu):New> <maas (Ubuntu Xenial):New> <maas (Ubuntu Zesty):New> <maas (Ubuntu Artful):New> <https://launchpad.net/bugs/1733615>
<heyya> So, I made some DNS changes to the MAAS files, and I noticed that the reverted.
<mup> Bug # changed: 1550083, 1706723, 1730976, 1730985, 1731059, 1731298, 1731353, 1731887, 1732220, 1732444, 1732522, 1732536, 1732539, 1732561, 1732730, 1732768, 1732948, 1733015
<roaksoax> heyya: MAAS manages DNS and they will be regenrated, what changes were you making ?
<bviktor_> is it not possible to install the maas server on centos?
<mup> Bug #1733442 changed: Cannot delete Virsh Pod <MAAS:Won't Fix by newell-jensen> <https://launchpad.net/bugs/1733442>
<roaksoax> bviktor_: if you use the snap, it could be
<roaksoax> we've not tested
<heyya> roaksoax: I wanted to know how to make it recursive
<heyya> as I am getting the following error. WARNING: recursion requested but not available
<roaksoax> ?
<heyya> DNS
<heyya> dnssec-validation auto;
<heyya> recursion;
<heyya> this file : /etc/bind/maas/named.conf.options.inside.maas
<heyya> when I dig against it, it does not resolve hostname from IP etc.
<bviktor_> well if snaps are as "universal" as they claim it, it shouldn't need to be "tested" though...
<bviktor_> oh, centos isn't even supported by snap anyway, oh well
<roaksoax> https://docs.snapcraft.io/core/install
<roaksoax> heyya: have you looked at the settings page in MAAS for the available configurable DNS settings ?
<heyya> are you reffering to DHCP snippets?
<heyya> sorry.. forgive the confusion.. ok.. all workig now
<heyya> lol
<heyya> I created a subnet and reserved dynamic range as I only need dhcp on a portion of that network.  There is an option to Enable "Managed allocation".  When I enable it, will it only enable dhcp on the "Reserve dynamic range" ?
<heyya> as that's what I'm trying to achieve
<heyya> I want to enable dhcp on a small portion of the network.
<mup> Bug #1733686 opened: [2.x, pod] MAAS pods should be allowed to be placed in a zone, and all machines inside the pod should have the same zone <MAAS:New> <https://launchpad.net/bugs/1733686>
<roaksoax> heyya: when you enable dhcp you only enable it on the 'dynamic' range
<roaksoax> heyya: so you have to define a dynamic range to enable dhcp
<mup> Bug #1733686 changed: [2.x, pod] MAAS pods should be allowed to be placed in a zone, and all machines inside the pod should have the same zone <MAAS:New> <https://launchpad.net/bugs/1733686>
<heyya> roaksoax: yeah, i figured i out.
<xygnal> TJ-: ipxe iso aways fails on ldlinux.c32
<xygnal> but my own sniffs from MAAS showed it for farther than two files, and ldlinux.c32 is not the first file
#maas 2017-11-22
<Dom_> hi everyone
<Dom_> I am a beginner in maas, and i'm trying to learn and understand the environment
<Dom_> In the production environment, we have region controller, rack controller, postgresql
<Dom_> can all of these exist in 1 server?
<Dom_> and when deploying our first MAAS server, do we need to have 3 physical servers, or shall we use something similar to vm, and create 3 vm servers with these?
<Dom_> 1 server ==> i mean physical server
<Dom_> The reason I have the confusion, when we say bare metal, then that means that this is main os that should be installed, and not to run it in a vm, is that correct?
<Dom_> Also, another question, MAAS does not create VMs
<Dom_> anyone online?
<Dom_> Guys?
<Dom_> is there anyone experienced in maas online?
<Dom_> do anyone at least know if I could install maas, juju on a single very large (spec) physical machine for production use?
<mup> Bug #1733592 opened: Wrong MTU values for container's NICs <cdo-qa> <cpe-onsite> <foundations-engine> <juju:Triaged by wpk> <MAAS:New> <https://launchpad.net/bugs/1733592>
<kiko> Dom_, yes, I do exactly that.
<kiko> Dom_, in fact, our foundation architecture does that across 3 machines
<kiko> Dom_, (it's early for the USA and also it's Thanksgiving week so bear with the delayed responses)
<Dom_> Hi Kiko, thanks!!
<Dom_> no, it's alright
<kiko> you can use a single physical server for MAAS region and rack
<kiko> for Juju, you can bootstrap into a VM on MAAS by using tags or specific placement
<kiko> into a VM [on the MAAS node] I meant
<kiko> MAAS does create VMs using it's new Pods feature
<kiko> Dom_, https://insights.ubuntu.com/2017/10/18/maas-kvm-pods/
<Dom_> So I can understand, where does MAAS stand out from esxi for example?
<kiko> MAAS itself isn't a hypervisor -- it's a provisioning tool
<mup> Bug #1733592 changed: Wrong MTU values for container's NICs <cdo-qa> <cpe-onsite> <foundations-engine> <juju:Triaged by wpk> <MAAS:New> <https://launchpad.net/bugs/1733592>
<Dom_> I've been into environments where we use esxi to split large physical machines into pieces
<kiko> gotcha
<kiko> so the KVM pods feature can do something similar
<Dom_> Hmm
<Dom_> We are trying to setup a cloud
<Dom_> as a base, MAAS got our interest, so currently we have 1 large physical machine
<Dom_> In the future, we are considering expanding the machines
<Dom_> but is it correct that we deploy Ubuntu MAAS as primary OS?
<kiko> correct, Ubuntu and then install MAAS
<Dom_> And then from there, we advance through the pods feature which uses KVM
<mup> Bug #1733592 opened: Wrong MTU values for container's NICs <cdo-qa> <cpe-onsite> <foundations-engine> <juju:Triaged by wpk> <MAAS:New> <https://launchpad.net/bugs/1733592>
<Dom_> so MAAS technically replaces ESXi with better provisioning, am I correct?
<Dom_> @Kiki, the reason I'm asking, we're not sure if we should install ESXi as a host, and then create 3 VMs for MAAS, or shall we just go directly for MAAS and let it handle what ESXi does?
<Dom_> Kiko, the reason I'm asking, we're not sure if we should install ESXi as a host, and then create 3 VMs for MAAS, or shall we just go directly for MAAS and let it handle what ESXi does?
<Dom_> Kiko, I'm asking from Virtualization perspective?
<kiko> Dom_, I'm confused -- can you explain what you are trying to make happen?
<Dom_> We want to host cloud services & applications, it might be also possible to host full vms, the company has dedicated a single large machine (from spec size) to use a test >> production, if successful, we may get more
<Dom_> physical machines
<Dom_> For us to setup this cloud correctly, we noted that MAAS takes care of the physical machine itself
<Dom_> even though there is confusion about the capabilities
<kiko> Dom_, you should get at least 3 machines to do a representative test
<Dom_> In our environment, we would initially setup ESXi (kind of a very minimized bootable service) then create VM for Windows /or Ubuntu for example
<Dom_> We are curious if we should really use MAAS directly instead of ESXi >> create VM for MAAS
<Dom_> Kiko, the test here will be production like environment, then move forward to getting other machines
<Dom_> Am I still confusing?
<kiko> (I'm on the phone so hang in for my response)
<Dom_> that's ok, tyt
<Dom_> sorry...
<Dom_> -.-
<Dom_> kiko
<kiko> I have long phone calls :)
<vogelc> roaksoax: is there a way to increase the verbosity of the maas logs?
<Dom_> i'm glad that the batteries lasted that long
<roaksoax> vogelc: rackd.log, maas.log is as verbose as it could be. regiond.log can be more verbose for http requests
<roaksoax> e.g. from the API
<vogelc> ok
<vogelc> roaksoax: have you explored using iPXE instead of pxe?
<mup> Bug #1732980 changed: MAAS incorrectly PXE boot UEFI/legacy boot <hp-proliant-dl380-g9> <maas> <pxe-boot> <uefi> <MAAS:Invalid> <https://launchpad.net/bugs/1732980>
<mup> Bug #1733900 opened: [2.3final, UI] Machines that have failed testing don't have an error icon <2.3qa> <ui> <MAAS:New> <https://launchpad.net/bugs/1733900>
<roaksoax> vogelc: yes, not a priority atm although we have some implementation proposed there for VM's so far
<roaksoax> vogelc: also, ipxe breaks RFC's
<heyya> is it possible to use Powerdns with maas?
<roaksoax> heyya: in what way ? instead of bind ? nope
<mup> Bug #1733923 opened: [2.3, HWTv2] badblocks test has 17 badblocks, but test shows as passed. <MAAS:Triaged by ltrager> <MAAS 2.3:Triaged> <https://launchpad.net/bugs/1733923>
<mup> Bug #1087183 changed: MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost' <amd64> <apport-bug> <cloud-installer> <landscape> <quantal> <MAAS:Fix Released by rvb> <pyjuju:Won't Fix> <https://launchpad.net/bugs/1087183>
<mup> Bug #1733592 changed: Wrong MTU values for container's NICs <cdo-qa> <cpe-onsite> <foundations-engine> <internal> <juju:Invalid by wpk> <MAAS:Invalid> <MAAS 2.3:Invalid> <https://launchpad.net/bugs/1733592>
<mup> Bug #1733945 opened: MAAS should warn loudly when it detects mismatched MTU settings <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1733945>
<mup> Bug #1733947 opened: MAAS should allow status transistion from FAILED_DEPLOYMENT to DEPLOYING or COMMISSIONING <MAAS:Triaged> <https://launchpad.net/bugs/1733947>
<mup> Bug #1733947 changed: MAAS should allow status transistion from FAILED_DEPLOYMENT to DEPLOYING or COMMISSIONING <MAAS:Triaged> <https://launchpad.net/bugs/1733947>
<heyya> roaksoax: I'm running MAAS in vmware.  is it possible to use juju charms to deploy windows 10?
<mup> Bug #1733947 opened: MAAS should allow status transistion from FAILED_DEPLOYMENT to DEPLOYING or COMMISSIONING <MAAS:Triaged> <https://launchpad.net/bugs/1733947>
<mup> Bug #1395904 changed: Need access to curtin install logs from past deployment <oil> <MAAS:Fix Released> <https://launchpad.net/bugs/1395904>
<mup> Bug #1395904 opened: Need access to curtin install logs from past deployment <oil> <MAAS:Fix Released> <https://launchpad.net/bugs/1395904>
<mup> Bug #1395904 changed: Need access to curtin install logs from past deployment <oil> <MAAS:Fix Released> <https://launchpad.net/bugs/1395904>
<mup> Bug #1733947 changed: MAAS should allow status transistion from FAILED_DEPLOYMENT to DEPLOYING or COMMISSIONING <MAAS:Triaged> <https://launchpad.net/bugs/1733947>
<trdillon1> Hello. I get lshw script failed with status: 139 during every commission
<trdillon1> So they all fail
<trdillon1> Any ideas what causes this?
#maas 2017-11-23
<mup> Bug #1389830 changed: Don't use wlan0 for cluster to region communication [when cluster and region are on same machine] <MAAS:Triaged> <maas (Ubuntu):Confirmed for lutostag> <https://launchpad.net/bugs/1389830>
<mup> Bug #1389830 changed: Don't use wlan0 for cluster to region communication [when cluster and region are on same machine] <MAAS:Triaged> <maas (Ubuntu):Confirmed for lutostag> <https://launchpad.net/bugs/1389830>
<mup> Bug #1389830 opened: Don't use wlan0 for cluster to region communication [when cluster and region are on same machine] <MAAS:Triaged> <maas (Ubuntu):Confirmed for lutostag> <https://launchpad.net/bugs/1389830>
<mup> Bug #1389830 changed: Don't use wlan0 for cluster to region communication [when cluster and region are on same machine] <MAAS:Triaged> <maas (Ubuntu):Confirmed for lutostag> <https://launchpad.net/bugs/1389830>
<mup> Bug #1734077 opened: [2.3final, UI] Machines that have failed testing don't have testing information in the cards and the Hardware tests tab is missing from the details page <2.3qa> <ui> <MAAS:New> <https://launchpad.net/bugs/1734077>
<mup> Bug #1734077 changed: [2.3final, UI] Machines that have failed testing don't have testing information in the cards and the Hardware tests tab is missing from the details page <2.3qa> <ui> <MAAS:New> <https://launchpad.net/bugs/1734077>
<mup> Bug #1734077 opened: [2.3final, UI] Machines that have failed testing don't have testing information in the cards and the Hardware tests tab is missing from the details page <2.3qa> <ui> <MAAS:New> <https://launchpad.net/bugs/1734077>
<corrrect_> I can't seem to resolve the hostname IP.  Does Maas configure reverse lookups
<corrrect_> I know I can simply add it. but wanted to know if MAAS configured that automatically
<corrrect_> as I don't see where to configure that.
#maas 2017-11-24
<heyya> DOes maas need to handle DNS?
<heyya> can I use something else for all DNS needs?
<trdillon1> I am getting the following on most of my nodes
<trdillon1>   /tmp/user_data.sh.Pw8oDH/scripts/commissioning/00-maas-01-lshw: line 6:  4436 Segmentation fault      (core dumped) sudo -n /usr/bin/lshw -xml
<trdillon1> I don't know how to fix it
<trdillon1> Ideas?
<trdillon1> It happens when commisioning
<mup> Bug #1734347 opened: No GUI feedback when libvirt pod out of disk space <error-surface> <pod> <MAAS:Triaged by newell-jensen> <https://launchpad.net/bugs/1734347>
<corrrect>  /join #synology
<mup> Bug #1734391 opened: user editing of preseed files is difficult due to maas internal data <MAAS:New> <https://launchpad.net/bugs/1734391>
<mup> Bug #1734391 changed: user editing of preseed files is difficult due to maas internal data <MAAS:New> <https://launchpad.net/bugs/1734391>
<mup> Bug #1734391 opened: user editing of preseed files is difficult due to maas internal data <MAAS:New> <https://launchpad.net/bugs/1734391>
#maas 2017-11-26
<atdprhs> Hi everyone, I'm trying to follow https://tutorials.ubuntu.com/tutorial/create-kvm-pods-with-maas?_ga=2.122713161.317020200.1511341689-1131947244.1511341689#2 by configuring the interfaces to http://paste.ubuntu.com/26047019/ , this cause my wifi not detecting any wifis around anymore after reboot, to fix it, I have to revert the settings back to http://paste.ubuntu.com/26047050/
<atdprhs> do anyone know what did I do wrong?
