| 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:14 |
|---|---|---|
| seffyroff | the tgt service being the main roadblock as my rackd won't sync images | 06:28 |
| seffyroff | i wondered if I'm hitting the OOM issue that tgt (once) had? | 07:07 |
| 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:38 |
| parlos | Good Morning | 07:39 |
| 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? | 07:40 |
| roaksoax | seffyroff: not yet | 08:03 |
| roaksoax | snas in 18.04 are currently broekn | 08:03 |
| seffyroff | ok thanks for the heads up. | 08:04 |
| seffyroff | I'll try some other approaches to getting this working | 08:04 |
| 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:06 |
| seffyroff | thanks! | 08:07 |
| 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:09 |
| 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:10 |
| 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:39 |
| 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:40 |
| 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. | 08:47 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| aln | oops - second url should be `/boot-resource/{id}/` of course | 10:24 |
| roaksoax | aln: deploy distro_series=xenial | 10:25 |
| roaksoax | aln: hwe_kernel=hwe-16.04 | 10:25 |
| roaksoax | aln: "name": "ubuntu/xenial", | 10:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:34 |
| 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:36 |
| roaksoax | aln: so I'm looking at our CI, and we use maas <user> machine deploy distro_series=win2012hrv2 | 10:38 |
| roaksoax | win2012hvr2 | 10:38 |
| 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:39 |
| 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:40 |
| roaksoax | aln: you should look at: https://github.com/maas/python-libmaas | 10:41 |
| 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 | 10:45 |
| 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 | 11:17 |
| ipat8 | Quick question for you guys | 13:27 |
| ipat8 | Is there a newer version of the maas-image-builder? | 13:27 |
| ipat8 | I can't seem to BZR branch it | 13:28 |
| ipat8 | ChanServ Who is allive? | 13:32 |
| ipat8 | *allive | 13:32 |
| ipat8 | *alive | 13:32 |
| neferty | i set up some VMs with manual power management and it seems like they never become ready, is this intentional? | 13:55 |
| 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:57 |
| 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:58 |
| neferty | oh hold on, i think i misunderstood when a machine is considered ready, my mistake | 13:59 |
| mup | Bug #1754697 opened: [FFe] Standing FFe for MAAS 2.4 <maas (Ubuntu):New> <https://launchpad.net/bugs/1754697> | 16:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!