| shang | bigjools: Q: are the maas-nocobbler being backported to precise yet? | 02:43 |
|---|---|---|
| bigjools | shang: it will be a couple of weeks yet | 02:43 |
| shang | bigjools: ah... ok :) | 02:43 |
| allenap | Daviey: Hello there guvnor. Do you want to talk about https://code.launchpad.net/~allenap/maas/remove-squashfs/+merge/133954 at all? | 11:06 |
| Daviey | allenap: not without mediation. :) | 11:07 |
| allenap | Daviey: Just a short quarrel? | 11:08 |
| Daviey | allenap: nah, not particularly.... I would rather issues were fixed, than just dropped.. but i'm not going to get emotional about it. | 11:08 |
| Daviey | allenap: It was really, that there was a fairly significant MP.. with no commentary as to why. | 11:09 |
| * Daviey alos notes there is no unit tests, testing the removal is solid :) | 11:09 | |
| allenap | Hehe :) | 11:09 |
| allenap | Daviey: I'd like to reintroduce it at some point, but without the imminent pressure of a release. | 11:10 |
| Daviey | allenap: do you want artificial pressure? | 11:12 |
| Daviey | allenap: TBH, the FPI might make it pointless to reintroduce | 11:13 |
| allenap | Daviey: That's cool too. | 11:13 |
| rbasak | Generally we want to merge stuff to trunk without breaking anything, right? And if it does break something, then we revert the merge and try again later? Otherwise we'd be red all the time. Think of this as just that? | 11:15 |
| Daviey | rbasak: Are you trying to use logic here? Why let logic get in the way of a perfectly good complaint. | 11:17 |
| rbasak | :) | 11:18 |
| rbasak | allenap: what's the current schedule? THere's some stuff I'm working on that I'd like to make for the SRU/whatever | 11:18 |
| * rbasak hadn't realised that anything was imminent | 11:19 | |
| allenap | rbasak: I don't know that there's a date other than as soon as we can. | 11:21 |
| rbasak | OK | 11:22 |
| allenap | Why won't lxc-start-ephemeral f****** work? | 12:23 |
| allenap | Ah, because it's a shell script silently ignoring an error code. | 12:23 |
| czajkowski | allenap: having a good day then are you! | 12:25 |
| allenap | czajkowski: Absolutely. MAAS has taught me to distrust everything written in shell. I'm still in the <rage> state though; not into acceptance yet. | 12:26 |
| roaksoax | allenap: why was import-squashfs removed? | 13:00 |
| roaksoax | Daviey ^^ | 13:02 |
| allenap | roaksoax: It's not working. There's some detail in https://code.launchpad.net/~allenap/maas/remove-squashfs/+merge/133954. | 13:33 |
| roaksoax | allenap: just responded to the comment | 13:34 |
| roaksoax | as a comment | 13:34 |
| roaksoax | smoser: howdy! what was the example package you gave me for the SRU from quantal to precise-updates? | 14:01 |
| smoser | walinuxagent | 14:02 |
| roaksoax | smoser: who should we talk to, SRU and security teams, right? | 14:03 |
| roaksoax | smoser: ah but walinuxagent is HW enablement, and its covered by the SRU policy | 14:03 |
| smoser | roaksoax, yeah, you're right on who to tlak to. | 14:06 |
| smoser | walinuxagent as HW enablement is BS. | 14:06 |
| smoser | but yeah, it was probably sold as such. | 14:06 |
| roaksoax | lol ok | 14:06 |
| smoser | we do have a valid interest. | 14:06 |
| smoser | its not like you and i just decided to do something sneaky and increase burdon for support. | 14:07 |
| roaksoax | indeed | 14:10 |
| Lele_ | Hi guys, is there any way to delete nodes once they are allocated | 14:11 |
| Lele_ | i have nodes ins status "allocated to root" | 14:11 |
| Lele_ | and i cannot delete them from the dashboard | 14:11 |
| Lele_ | cause the delete button is greyed out and says "you cannot delete this node cause its in use" | 14:12 |
| Lele_ | and im the owner of it | 14:12 |
| Lele_ | if i delete them from the maas shell, its a correct procedure ? | 14:17 |
| Lele_ | Node.objects.get() | 14:17 |
| Lele_ | and then .delete | 14:17 |
| melmoth | Lele_, i dont know the internals, but what about first juju-terminate the services (or units) that maas thinks run on this machine ? | 14:19 |
| rvba | Lele_: yes, that's the correct 'manual' procedure. | 14:19 |
| Lele_ | melmoth i was going to integrate maas with juju now, and i need 3 deallocated nodes, when i was ready to delete one to start the task i found that i cannot delete "cleanly" without juju integration | 14:27 |
| Lele_ | so it was kinda egg-chicken situation | 14:27 |
| Lele_ | im going to delete it from the maas shell, hope that all the other "dependant" services get cleaned ok | 14:28 |
| Lele_ | ok rvba im going to do that way | 14:28 |
| Lele_ | hmmm, seems that the shell doest allow me to do this either | 14:29 |
| Lele_ | NodeStateViolation: Cannot delete node node-be1bc94e-29ec-11e2-bbd6-0025901e4c74: node is in state Allocated. | 14:29 |
| allenap | Lele_: The node needs to be released first, which can be done via the command line. | 14:30 |
| allenap | Lele_: It sounds like you might not want to delete the node, just release it back to MAAS. | 14:31 |
| Lele_ | allenap, with the maas-cli ? | 14:31 |
| Lele_ | yep thats what i want allenap | 14:31 |
| allenap | Lele_: Yeah.# | 14:31 |
| Lele_ | allenap, about that, i cant find the docs, whats the correct url to do the maas login | 14:33 |
| Lele_ | so im getting and empty reply from the servers | 14:33 |
| Lele_ | cause i get a 302 | 14:33 |
| Lele_ | i tried: maas-cli login maas http://172.16.167.14/MAAS/api/v1.0 | 14:34 |
| Lele_ | maas-cli login maas http://172.16.167.14/MAAS/api/v2.0 | 14:34 |
| Lele_ | maas-cli login maas http://172.16.167.14/MAAS/api/ | 14:34 |
| allenap | Lele_: maas-cli login maas http://172.16.167.14/MAAS should be enough. | 14:34 |
| Lele_ | ok ill try allenap | 14:34 |
| Lele_ | niceeee im in allenap thanks | 14:35 |
| allenap | Lele_: Now: maas-cli maas node release <system-id> | 14:36 |
| allenap | Though finding out the system ID might take another step. | 14:36 |
| allenap | maas-cli maas nodes list-allocated | 14:36 |
| Lele_ | yep allenap maas-cli maas nodes lists | 14:37 |
| === matsubara is now known as matsubara-lunch | ||
| Lele_ | allenap will be nice if the "status" of the node, on the JSON response, had a status_description | 14:39 |
| Lele_ | for example 6 is allocated | 14:39 |
| Lele_ | etc | 14:39 |
| Lele_ | so if we use the json output on a python script we dont need to mantain mappings within the status codes ids | 14:40 |
| allenap | Lele_: Yes, agreed. rvba, can we get Piston to emit read-only fields? i.e. we create a status_description property on the model and Piston serialises it, but ignores it on write? | 14:41 |
| rvba | allenap: yes. A property on the model will work. | 14:45 |
| Lele_ | allenap , rvba NICE :) | 14:47 |
| roaksoax | smoser: do you think we should start shipping maas-signal and maas-autodetect-ipmi with maas source itself? | 15:24 |
| roaksoax | or at least with the packaging | 15:24 |
| roaksoax | ? | 15:24 |
| smoser | it would seem to make sense for them to be in maas upstream source, yeah. | 15:25 |
| smoser | and then a binary package built from that. | 15:25 |
| smoser | thats a good idea. | 15:25 |
| smoser | or at least i can't think of any reason why not | 15:25 |
| roaksoax | ok cool | 15:25 |
| roaksoax | smoser: i think we should also start looking at dropping maas-enlist | 15:28 |
| smoser | roaksoax, where did that function move to ? | 15:30 |
| roaksoax | smoser: if we are backporting | 15:31 |
| roaksoax | smoser: poh hold on, the installer still uses it | 15:31 |
| roaksoax | swo never mind :) | 15:31 |
| === matsubara-lunch is now known as matsubara | ||
| roaksoax | rvba: howdy! how do I add tests to scripts I'd like to add to maas/contrib? | 15:52 |
| rvba | roaksoax: the natural place for a script would be scripts/. Why do you want to put it in contrib/ ? | 15:57 |
| roaksoax | rvba: err yeah, scripts :) | 15:58 |
| roaksoax | rvba: i'm g0onna place two new scripts there, and I'd like to also add the tests for them | 15:58 |
| roaksoax | rvba: and that probably will create a new binary package | 15:59 |
| rvba | roaksoax: you can have a look at src/provisioningserver/tests/test_maas_import_pxe_files.py | 15:59 |
| rvba | That's a good example of tests testing a script. | 16:00 |
| roaksoax | rvba: cool thanks. But now, where should the test be placed ? (these scripts only affect enlistment/commissioning process, so they don't really belong anywhere under src/*) | 16:00 |
| rvba | roaksoax: these scripts are going to end up in a different package right? | 16:01 |
| roaksoax | rvba: most likely yes | 16:02 |
| rvba | roaksoax: then I think the best option is to create another module in src/. | 16:02 |
| rvba | allenap: any opinion on that? ^ | 16:02 |
| roaksoax | smoser: on the ipmi detection, do you think it would be a good idea to wait 60 seconds before obtaining the IP address of the IPMI card at all ties? | 16:07 |
| roaksoax | times* | 16:07 |
| smoser | why would you do that? | 16:07 |
| roaksoax | smoser: becuase there's some situations on which it obtains a 0.0.0.0, and appears to be that the IP address gets set after that | 16:08 |
| roaksoax | smoser: due to maybe DHCP taking to much time, or maybe due to IPMI failing to query the card correctly | 16:08 |
| roaksoax | smoser: i.e., in my home setup, enlistment gets IP address for 2 servers correctly, but the third one gets 0.0.0.0, however, the IPMI card does have an IP address set, and it seems that the bmc command failed to correctly obtain the IP address | 16:09 |
| roaksoax | maybe the card requested the address again or something | 16:09 |
| roaksoax | so in that case it would kinda make sense to wait 60seconds and try again | 16:09 |
| roaksoax | and if it doesn't work, then exit | 16:10 |
| roaksoax | smoser: http://paste.ubuntu.com/1355779/ | 16:10 |
| smoser | roaksoax, i guess that "wait some time and try again if ip looks invalid" is ok. | 16:13 |
| smoser | but i didn't want "always wait 60 seconds" | 16:13 |
| smoser | as we dont want to delay the "all working" path | 16:13 |
| roaksoax | right :) | 16:14 |
| roaksoax | thought so too hence the diff | 16:14 |
| roaksoax | alright, thanks for the input | 16:14 |
| roaksoax | smoser: i think that probably on commissioning we might no longer need to try to detect the IP address of the card, as it would/should be the same | 16:15 |
| smoser | roaksoax, that also does seem reasonable. | 16:19 |
| roaksoax | yep, I'll get that updated then | 16:20 |
| === pcarrier_ is now known as pcarrier | ||
| bigjools | o/ roaksoax | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!