[09:01] <rvba> gmb: btw, did you get around to writing that new FAQ entry in the doc we talked about yesterday (or the day before)?
[09:02] <gmb> Fiddlesticks, no.
[09:02] <gmb> I’ll do that presently.
[09:02] <rvba> Cool.
[09:23] <gmb> rvba: Tiny review for you: https://code.launchpad.net/~gmb/maas/doc-change/+merge/216271
[09:23] <rvba> gmb: approved
[09:24] <gmb> Th
[09:24] <gmb> x
[10:12] <alfs> Hi, I'm in the process of getting an openstack cloud running via the maas+juju route
[10:13] <alfs> Regarding page http://maas.ubuntu.com/docs/juju-quick-start.html , can you please update the sync-tools command? Page says juju --sync-tools, it should be juju sync-tools
[10:13] <alfs> Again, the page should also clearly state that some nodes must be in the Ready state.
[10:13] <alfs> I was playing with my maas-machines, and had all allocated when I tried to bootstrap.
[10:14] <alfs> Got error "gomaasapi: got error back from server: 409 CONFLICT"
[10:15] <alfs> (which really did not help) - found a QA page that suggested maas-cli files list and removing some provisionging files. Did not work.
[10:16] <alfs> Finally I realized that perhaps the bootstrapping needed "ready" nodes, tried that and it worked. So I suggest a) having a more helpful error than "409 CONFLICT" and b) update the quick-start guide to clearly state this (it says "at least 2 nodes enlisted", which is too ambiguous)
[10:18] <alfs> I also wonder if there is a way to release nodes from the web interface? Now I did it via maas-cli nodes list, getting the system id, then maas-cli node release node-nnnn. But is there some simpler way of releasing?
[10:22] <gmb> alfs: Thanks for the documentation feedback. Would you mind filing a bug about this so we can track the work (https://bugs.launchpad.net/maas/+filebug)?
[10:22] <alfs> sure
[10:22] <rvba> alfs: Hi, thanks for the feedback.  I think we have a bug about the fact that the "conflict" error is not really helpful… let me see if I can find it.
[10:23] <rvba> alfs: you should be able to release nodes from the UI by using the "Stop" button or the "Stop nodes" bulk action.
[10:26] <alfs> Ok - can't find a stop node, only action is a greyed out delete node. (Perhaps I'm running an old version, anyway it's from the cloud-archive:tools repository
[10:27] <alfs> 1.2+bzr1373+dfsg-0ubuntu1~12.04.5
[10:28] <rvba> Yeah, it's a bit old and that's probably why the stop button isn't there.
[10:29] <alfs> btw, is trusty available in later maas releases (seeing that it should be a final release today :))
[10:30] <rvba> alfs: yes, MAAS 1.5 is in Trusty. See https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes.
[10:48] <rvba> gmb: can you confirm that the version switcher widget is displayed correctly on maas.ubuntu.com/docs ?
[10:48] <rvba> (I had to fight with the cache here but it might be because I requested that page when I was still syncing the documentation)
[10:49] <gmb> rvba: Yep. Looks good.
[10:49] <rvba> gmb: does it include version 1.3?
[10:49] <gmb> Yes
[10:49] <rvba> Ok, cool.  Thanks for checking.
[10:49] <gmb> np
[10:51] <alfs> I did an apt-get update + upgrade on my installation, got to maas 1.4, and now there is a "stop node" and "use the fast installer" action buttons.
[10:52] <alfs> now going for a do-release-upgrade -d to trusty and see how that works out
[13:11] <alfs> would it be possible to provision to a ram-disk instead of permanent storage? ie. like the enlisting boot, but with a "full" installation
[13:12] <rvba> alfs: no, disk-less provisioning is currently not supported.  But it's on our radar :).
[13:13] <alfs> that would be really nice, we've got rooms of student workstations that need to have a windows installation daytime, but could then be used as a cloud at night and weekends
[13:47] <bladernr_> Hey, out of curiosity, how long will it take after the release announcement to get official 14.04 PXE and Ephemeral images for MAAS?
[13:47] <bladernr_> (how long shoud I wait before updating my maas server?
[13:51] <rvba> bladernr_: rc images are already in place.
[13:51] <rvba> smoser: how long before the 'release' images are in place?
[13:52] <bladernr_> rvba: cool... so to confimr then, the current RC images are considered officially golden?
[13:52] <bladernr_> confirm, even...
[13:53] <rvba> bladernr_: I think so… but let's get smoser to confirm that 'officially' :).
[13:53] <smoser> bladernr_, RC images are not golden, no.
[13:53] <smoser> but i'm not sure why you're concerned about when you shoudl update.
[13:53] <rvba> smoser: oh?
[13:53] <smoser> just update
[13:53] <smoser> and then update again
[13:54] <smoser> and then again
[13:54] <smoser> (as you can, and should do)
[13:54] <bladernr_> ok... the reason I asked is that the TPMs, FEs and Cert team wanted to know how long they needed to wait to update to "Official 14.04 PXE and ephemerals" for official certification testing on Server
[13:54] <bladernr_> if I update a maas server NOW, and start cert testing, I may not be using actual Golden images there
[13:54] <bladernr_> thus my cert would be unacceptable
[13:55] <smoser> well, that makes some sense.
[13:55] <bladernr_> yeah, it's not so much a matter of function as it is just paperwork and official blessing
[13:55] <smoser> but in reality, the nature of maas (and the ubuntu archive) is that you testing something "now" bears no actual guarantee on someone running it tomorrow.
[13:56] <bladernr_> right, but from a contractual point of view, saying "It's Certified on Beta 2" is one thing (unsupported) but saying "It's supported on 14.04 GA" means "It's supported until 14.04 is EOL"
[13:56] <bladernr_> err... saying "It's CERTIFIED on 14.04 GA"
[13:56] <smoser> bladernr_, actually what is in 'daily' right now is what i would hope to make 'release' later today.
[13:57] <bladernr_> me too... heh... no respins!
[14:16] <smoser> bladernr_, ok. so what is there now is crap (in daily).
[14:17] <smoser> it missed a bunch of stuff.
[14:51] <alfs> gettings hickups in the commissioning, the installerer halts at "download installer components", no kernel modules were found
[14:51] <alfs> and requires console interaction
[14:53] <alfs> basically added trusty to bootresources.yaml and import-pxe-files
[14:57] <rvba> alfs: this is https://bugs.launchpad.net/maas/+bug/1302158
[14:58] <rvba> smoser: I thought this (^) would disappear now that the kernels are "stable"…?
[14:58] <alfs> ah, ty :). Will let it rest until tomorrow
[14:58] <rvba> alfs: did you run the import script again to make sure you have the latest imageS?
[15:00] <alfs> yes, I ran it a number of times, there were also some problems, e.g. a .part file missing, next time a bad checksum, then a missing pgp key, and then it completeted
[15:02] <smoser> rvba, it will
[15:02] <alfs> anyway, I'm going for a clean trusty maas install, there may be some artifacts of upgradings and my hacking around
[15:02] <smoser> rvba, we'res till out of date
[15:03] <smoser> working on that right now. thought i had it last night, but messed up something.
[15:04] <rvba> smoser: okay
[15:04] <rvba> Thanks for the heads up.
[16:09] <smoser> rvba, bladernr_ we should be good now in daily.
[16:10] <smoser> and the plan will be to promote 20140416 builds to release here shortly
[16:29] <bladernr_> smoser: should this be necessary now:
 bladernr, you need to modify bootresources.yaml to point to the daily directory to get anything newer than april 10th (that's what I had to do)
[16:30] <bladernr_> that was just to pull trust dailies...
[16:30] <bladernr_> we should be able to revert that today, yes?
[16:32] <bladernr_> smoser: nevermind, now that I poked around a bit I see what you were saying.
[16:33] <smoser> yeah, so dailies now have 20140416 stuff.
[16:33] <smoser> but releases does not.
[16:36] <bladernr_> smoser: ack... thanks
[18:47] <Kupo24z> Hey all, are trusty release maas boot images avalible? All im getting are RC
[19:02] <bladernr_> question... in bootresources.yaml, theres a selections: &id001 and a selections: *id001 in two different sections (Daily and Releases)
[19:02] <bladernr_> does that mean maas-import-pxe-files will look for the same selections in both releases and daily on maas.ubuntu.com?
[19:03] <bladernr_> e.g. is *id001 just a pointer back to everything that follows under &id001?
[19:16] <blahRus> Bump for 14.04 maas images???