[06:14] <seffyroff> Hello folks!  I'm in early stages with my discovery project to spin up MaaS inside a Docker container, right now I'm seeing some errors related to the tgt service not starting, and some ntp resolution socket errors too - as I'm running in a containerized snap, I theorized that there's some additional channels I could connect for a more relaxed runtime environment
[06:28] <seffyroff> the tgt service being the main roadblock as my rackd won't sync images
[07:07] <seffyroff> i wondered if I'm hitting the OOM issue that tgt (once) had?
[07:38] <parlos> I'm hoping to use MAAS as a orchestrator in a lab environment. Hence; I under stood that the way to go is to have multiple user accounts, and then acquire hosts to that user. Now; can I as an admin assign nodes to a user, or can this only be done from the user account?
[07:39] <parlos> Good Morning
[07:40] <seffyroff> hmm, looks like the tgt changes for 2.4.0 might help me here
[07:40] <seffyroff> i guess there's no snap for that?
[08:03] <roaksoax> seffyroff: not yet
[08:03] <roaksoax> snas in 18.04 are currently broekn
[08:04] <seffyroff> ok thanks for the heads up.
[08:04] <seffyroff> I'll try some other approaches to getting this working
[08:06] <roaksoax> seffyroff: you should probably look at 2.3.1
[08:06] <roaksoax> it had a tgt fix running in containers (lxc)
[08:06] <seffyroff> yup, db migrations happening as we speak
[08:07] <seffyroff> thanks!
[08:09] <roaksoax> parlos: there's no suhc way to assign a machine to a user. Users/admins have acces to a machine pool, and they can allocate themselves a machine
[08:10] <parlos> roaksoax: so, if I want to limit what nodes a user can use, I have to login as user an acquire the nodes as that user... any plans for that?
[08:39] <seffyroff> actally roaksoax i do see a 2.4.0 snap, but I guess it'll sulk if I try to install it on a Xenial host?
[08:40] <seffyroff> channels:
[08:40] <seffyroff>   stable:          2.3.0-6434-gd354690-snap        (1349) 101MB -
[08:40] <seffyroff>   candidate:       2.3.1-6470-g036d646-snap        (1868) 100MB -
[08:40] <seffyroff>   beta:            2.3.1-6470-g036d646-snap        (1868) 100MB -
[08:40] <seffyroff>   edge:            2.4.0~alpha2-6630-gc925539-snap (1857) 97MB  -
[08:47] <seffyroff> hm, tgt still wouldn't start from 2.3.1 snap inside a docker container.  It does start if I snap install to the host itself though.
[10:18] <roaksoax> seffyroff: the 2.4 snap requires ubuntu core 18
[10:18] <aln> is anyone able to answer a basic question about the API?
[10:18] <roaksoax> seffyroff: which is still in development
[10:19] <seffyroff> noted, thanks
[10:19] <seffyroff> looks like i'll go for package install, which I was leaning towards anyway so I can apply a downstream WOL patch
[10:20] <seffyroff> although possibly similar could be accomplished with snap scriptlets
[10:20] <roaksoax> aln: sure, just ask your question and if soneone knows the answerm, they will reply
[10:21] <seffyroff> it'll potentially produce a cleaner container also.  So much low level hackery to get snap running in the contaienr first, then maas requires several additional hacks to work within snap within a container >.<
[10:22] <aln> i want to deploy a machine with the api using `/machines/{system_id}/?op=deploy`. i would have expected it to take boot-resource ID as a parameter but instead it takes distro_series and hwe_kernel.
[10:23] <aln> i tried to fetch information about the boot-resource from `/boot-sources/{id}/`, but this does not return any information that seems to fit into distro_series or hwe_kernel.
[10:23] <aln> how can i issue a deploy via the api and specify the boot-resource/image i want to use?
[10:23] <aln> (deploy works, i just can't get it to use anything other than the default image)
[10:24] <aln> oops - second url should be `/boot-resource/{id}/` of course
[10:25] <roaksoax> aln: deploy distro_series=xenial
[10:25] <roaksoax> aln: hwe_kernel=hwe-16.04
[10:25] <roaksoax> aln:         "name": "ubuntu/xenial",
[10:26] <roaksoax> aln:         "subarches": "generic,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t,hwe-u,hwe-v,hwe-w,ga-16.04,hwe-16.04,hwe-16.10"
[10:26] <aln> u'name': u'ubuntu/xenial',
[10:26] <aln> u'subarches': u'generic,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t,hwe-u,hwe-v,hwe-w,ga-16.04'
[10:26] <aln> yeah, sorry haha
[10:26] <roaksoax> aln: yeah, although the subarches you can only use ga-16.04, hwe-16.04, etc
[10:26] <roaksoax> at least that's on ym streams
[10:27] <aln> okay
[10:27] <aln> and this works with custom non-linux images too?
[10:27] <aln> so, u'name': u'windows/win2012r2'
[10:27] <aln> u'subarches': u'generic',u'name': u'windows/win2012r2'
[10:28] <aln> i can specify win2012r2 and generic?
[10:28] <roaksoax> aln: for non-ubuntu deployments, you dont need to set the hwe_kernel
[10:28] <roaksoax> aln: the hwe_kernel is only really valid for ubuntu, because that's the kernle the machine will be running post deployment
[10:28] <aln> yes of course, thanks
[10:29] <roaksoax> aln: as for windows, distro_series=win2012r2
[10:29] <roaksoax> aln: it should workt distro_series=windows/win2012r2
[10:29] <roaksoax> but doens't necessarily
[10:29] <aln> yeah, it didn't for me
[10:29] <roaksoax> but it is not necessary
[10:29] <roaksoax> ok, yeah that seems like a bug
[10:34] <aln> roaksoax: thanks for the help, but afraid this didn't work
[10:34] <aln> issuing request with distro_series=windows2012r2 makes it deploy xenial
[10:36] <roaksoax> aln: it doens't deployxenial, it pxe boots into xenial to deploy windows
[10:36] <aln> status: Deploying Ubuntu 16.04 LTS
[10:36] <roaksoax> aln: ah1 that's stranger
[10:36] <roaksoax> strange
[10:36] <roaksoax> what version you using ?
[10:36] <aln> of maas?
[10:36] <aln> 2.3.0
[10:38] <roaksoax> aln: so I'm looking at our CI, and we use maas <user> machine deploy distro_series=win2012hrv2
[10:38] <roaksoax> win2012hvr2
[10:39] <roaksoax> so aln we test that path
[10:39] <aln> Deploying Ubuntu 16.04 LTS
[10:39] <aln> but presumably that's what is after the slash in your boot-resource's name
[10:40] <roaksoax> right, so if boot-resource's name is <os>/<series> on distro_series= just use the <series>
[10:40] <aln> yeah
[10:40] <aln> Deploying Ubuntu 16.04 LTS
[10:40] <roaksoax> aln: also, if you are talking directly to the API, not via the CLI
[10:41] <roaksoax> aln: you should look at: https://github.com/maas/python-libmaas
[10:45] <aln> i did have a look at this, but we decided just to interface directly, as we don't need to use it much (='my boss told me to do it this way')
[10:45] <roaksoax> gotcha
[10:45] <aln> looking though the library for an example of the call being made for deploy, but it's pretty abstracted
[11:17] <aln> if anyone reads my messages above and think they can help, i made a post here: https://askubuntu.com/questions/1013371/specifying-boot-resource-for-maas-api-deploy
[13:27] <ipat8> Quick question for you guys
[13:27] <ipat8> Is there a newer version of the maas-image-builder?
[13:28] <ipat8> I can't seem to BZR branch it
[13:32] <ipat8> ChanServ Who is allive?
[13:32] <ipat8> *allive
[13:32] <ipat8> *alive
[13:55] <neferty> i set up some VMs with manual power management and it seems like they never become ready, is this intentional?
[13:57] <wiro> neferty: they should be ready after commisioning, then you have to turn them off manualy
[13:57] <neferty> i have turn them off? eh, alright
[13:58] <wiro> no necessary, it should be on byt after commisioning it reched ready state, if not then there should be some error
[13:58] <wiro> in test or commision
[13:59] <neferty> oh hold on, i think i misunderstood when a machine is considered ready, my mistake
[16:15] <mup> Bug #1754697 opened: [FFe] Standing FFe for MAAS 2.4 <maas (Ubuntu):New> <https://launchpad.net/bugs/1754697>