[10:07] <jam> mgz: now we just hear ourselves echo on about a 1s delay
[11:15] <evilnickveitch> question: is there any reason for the end user to use the 'maas' command for anything other than "createsuperuser" and "changepassword"?
[11:19] <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.
[11:19] <evilnickveitch> rvba: thanks!
[11:19] <rvba> np
[13:14] <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?
[13:40] <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).
[13:41] <allenap> rbasak: The problem with maas-import-ephemerals is that there are no tests, so it's hard to refactor.
[13:41] <rvba> allenap: thanks for the reviews.  You're so quick I don't even have to ask. :)
[13:42] <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.
[13:42] <allenap> rvba: No worries.
[13:42] <rbasak> I think it's gone beyond the point where shell is appropriate. smoser might disagree though!
[13:43] <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.
[13:43] <smoser> i dont really care, but i generally disagree with any sort of "cannot be tested BS".
[13:44] <smoser> test the freaking thing.
[13:44] <smoser> dont pretend you do by running 'make test' that mocks 90% of it.
[13:44] <allenap> rbasak: I think >1 line of shell is beyond appropriate, but some might say that's extreme.
[13:44] <smoser> but, sure, rewrite if you feel like it.
[13:44] <allenap> smoser: Do you mean automated testing, or manual?
[13:45] <smoser> well, when you make changes you should do test of your changes. period.
[13:45] <smoser> not writing unit tests that pretend to test.
[13:45] <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.
[13:45] <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.
[13:45] <rbasak> (though I would be fine if smoser disagreed with that - I'm only slightly on the side of python on this one)
[13:46] <smoser> there shoudl be some sort of ci testing in place. but, yes, if you change things, you should test them.
[13:46] <smoser> that really should not be questionable.
[13:47] <smoser> there should also be some sort of easily runnable "setup and test". we're lacking in that department.
[13:47] <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?
[13:47] <smoser> so people take short cuts. and do not test their code in reality.
[13:47] <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.
[13:48] <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....
[13:49] <smoser> that would at least test the expected user path
[13:49] <matsubara> we're at that point
[13:49] <matsubara> with the CI tests in jenkins
[13:49] <rvba> That's what the integration tests do.
[13:49] <matsubara> and yes, the CI tests did catch some bugs in maas-import-pxe-files
[13:50] <smoser> matsubara, can allennap  run that?
[13:50] <smoser> and does he need access to hardware to do so?
[13:50] <rvba> No, he just needs an account on the jenkins instance.
[13:50] <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.
[13:50] <matsubara> smoser, yes and no (although he does have access to the lab)
[13:50] <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?
[13:51] <matsubara> but yes, I agree that if maas-import-pxe-files tests could be part of the maas test suite, that would be nice
[13:51] <smoser> matsubara, we need to remove the necessity of "lab access" also.
[13:51] <matsubara> smoser, lab access is useful to debug when the CI tests fail
[13:51] <smoser> matsubara, clearly, yes.
[13:51] <smoser> it can all run (minus ipmi) inside an instance[s] and a subset of that can run on a local system.
[13:52] <smoser> ie, "all in one" can run on a single system. or a single vm with nested virt.
[13:52] <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.
[13:52] <smoser> i didn't say that unit tests are not useful.
[13:52] <smoser> i said they're not complete. and you should test code you write.
[13:52] <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
[13:52] <smoser> and not doing so is unacceptable.
[13:53] <rbasak> matsubara: ok, but in general?
[13:53] <smoser> i'll end my rant.
[13:53] <matsubara> rbasak, apart from that the CI infrastructure should be working
[13:53] <rbasak> What if the lab tested merge proposals or just maas branches on demand and sent us the results?
[13:53] <rbasak> matsubara: and can it do what I mentioned above?
[13:53] <smoser> rbasak, right.
[13:53] <smoser> and then, we want to detach that from the lab.
[13:53] <matsubara> rbasak, it does that for the unit tests test suite, but not for the CI
[13:54] <matsubara> currently CI tests takes around 30 mins including juju tests
[13:54] <matsubara> so blocking landings on CI, would make development speed a lot slower
[13:54] <rbasak> '
[13:54] <rbasak> I'm happy with that for maas-import-pxe-files changes. We don't change it that often. A day would be fine
[13:54] <matsubara> cool
[13:55] <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.
[13:55] <rbasak> So do we have the facility to automatically test that MP now?
[13:55] <allenap> rbasak: I /think/ we need to land it before it'll be visible to the acceptance suite. Is that correct, matsubara?
[13:56] <smoser> allenap, assuming QA will catch stuff is rude.
[13:56] <matsubara> yes allenap and rbasak
[13:56] <smoser> ie, assuming the first time it will run in an actual environment rather than unit test is the failure.
[13:57] <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?
[13:57] <smoser> wait. thats not a sentance.
[13:57] <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.
[13:58] <smoser> rbasak, what is the MP ?
[13:58] <smoser> link ?
[13:58] <rbasak> smoser: https://code.launchpad.net/~racb/maas/multi-soc-ephemerals/+merge/134715
[13:59] <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.
[14:00] <smoser> rbasak, you need to use more quotes.
[14:01] <smoser> cp $src/subarch/$subarch/initrd.gz needs to be cp "$src/subarch/$subarch/initrd.gz"
[14:01] <smoser> as src can have space and yo ufail.
[14:01] <smoser> i dont do things like that just for fun.
[14:01] <rbasak> smoser: that's fine
[14:02] <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.
[14:02] <smoser> you *do* have the facility.
[14:02] <smoser> allenap, do you ahve a canonistack account?
[14:02] <smoser> if not, you should.
[14:03] <allenap> smoser: Yes, but that's not a representative environment.
[14:03] <smoser> allenap, it is for the test in question. (and actually just about everything we do other than ipmi)
[14:04] <rbasak> Very little of bits that matter for ARM though
[14:04] <smoser> ?
[14:04] <smoser> there are some arm specific paths. thats true. but the majority of this is not arch specific.
[14:05] <allenap> smoser: How does canonistack help us test DHCP and PXE better than a unit test?
[14:06] <rbasak> allenap: it would test that stuff actually works, rather than what a unit test tests
[14:07] <Daviey> you can PXE install using canonistack.
[14:07] <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
[14:07] <rbasak> That was happening every other day or so
[14:07] <rbasak> It appeared that I was the only one trying trunk on real hardware all the way through at the time
[14:08] <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?
[14:08] <rbasak> (the situation is a lot better now thanks to the automation that matsubara has done)
[14:09] <rbasak> But it demonstrates well that the unit tests are not sufficient, especially for the system-level parts like dhcp, pxe, ipmi, etc.
[14:09] <allenap> rbasak: I agree, when things need hardware there's usually little option but to go to hardware.
[14:09] <rbasak> dhcp and pxe don't need hardware for non-IPMI. KVM will do
[14:09] <Daviey> allenap: pxe-tftp tool :)
[14:09] <Daviey> pxe-kexec, rather
[14:10] <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)
[14:10] <smoser> rbasak, i commented.
[14:11] <allenap> Daviey: That's pretty cool. Doesn't test our DHCP integration, but it's neat, granted.
[14:11] <smoser> you dont need pxe-kexec.
[14:11] <smoser> you actually boot a vm
[14:11] <smoser> and let the bios pxe boot
[14:11] <smoser> just like a real machine.
[14:12] <smoser> rbasak, i updated mp.
[14:12] <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
[14:13] <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.
[14:13] <smoser> (at least in the short term)
[14:13] <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).
[14:14] <smoser> allenap, i will agree with you on that.
[14:15] <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.
[14:15] <rbasak> allenap: and who is going to refactor it?
[14:16] <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).
[14:19] <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.
[14:19] <rbasak> Understood. My work on apt is in the same situation.
[14:20] <rbasak> There are a couple of other factors there though. Not sure how much they apply though
[14:20] <rbasak> For an SRU, I wouldn't normally want to do a refactor. Minimal change would almost always be better.
[14:20] <rbasak> Here though, maas is a bit special with its SRU
[14:22] <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
[14:23] <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
[14:44] <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.
[15:12] <rnbrady> Hi guys
[15:12] <rnbrady> Just been playing with maas over last week and loving it.
[15:12] <rnbrady> But still haven't got my first server up.
[15:13] <rnbrady> So far I have the maas server running, enlisting nodes, and serving some pxeboot.
[15:13] <rnbrady> But getting lots of weirdness in the commissioning process and could use a few tips if anyone about.
[17:02] <roaksoax> rvba: do you recall when was the apprmor stuff uploaded... or in what package version?
[17:04] <roaksoax> smoser: ^^ do you?
[17:06] <roaksoax> rvba: the fix for it is already in -proposed and needs verification: 1049177
[17:06] <roaksoax> rvba: the fix for it is already in -proposed and needs verification: bug #1049177
[17:06] <roaksoax> rvba: could you please get that tested?
[17:07] <rvba> roaksoax: thanks.  Sure I'll test that.  I need to bugger off now but I'll do it tomorrow.
[17:08] <roaksoax> rvba: cool thanks
[17:26] <smoser> roaksoax, did you get what you wanted?
[17:37] <roaksoax> smoser: yes, thanks!
[19:33] <roaksoax> matsubara-brb: how do you configure maas dhcp server?
[19:33] <roaksoax> and enable it?
[19:39] <matsubara> maas-cli maas node-groups list | grep uuid
[19:39] <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
[19:39] <matsubara> roaksoax, ^
[19:39] <roaksoax> matsubara: cool thanks
[19:42] <matsubara> np
[19:57] <rnbrady> Newbie question. For maas-cli, is the profile name arbitrary?
[19:57] <rnbrady> I can do maas-cli login maas or maas-cli login iamoneleggedman, and both work.
[20:01] <matsubara> yes rnbrady
[20:01] <rnbrady> Tks. So it's just an alias for an API from what I have since discovered.
[20:02] <rnbrady> Nifty! Just issued my first maas-cli maas start xxx
[20:02] <rnbrady> The thrill of hearing fans whirring spontaneously on the other side of the room and the press of a key
[20:02] <rnbrady> s/and/at/
[20:16] <rnbrady> Currently trying to work out how to do a named deployment, as I am only getting the option to queue for allocation.
[20:33] <rnbrady> Ok, which one of you sadists commented out NODE_AFTER_COMMISSIONING_ACTION.DEPLOY_12_04 from NODE_AFTER_COMMISSIONING_ACTION_CHOICES?
[21:32] <rnbrady> Wahoo! It's alive! Named deployment 12.04!