[04:02] <hallyn> using ppa:maas/stable on xenial, doing createadmin, the first time it failed due to proxy to fetch ssh keys, so i do it again, then it fails with an error message about fetching duplicate keys
[04:03] <hallyn> which is fine if it's the last thing, but not fine if it's skipping some other setup as a result
[04:04] <hallyn> (and it doesn't tell me)
[05:27]  * hallyn looks around for a no_proxy setting
[07:11] <mpontillo> hallyn: don't worry, fetching the keys comes last ;-)
[08:06] <zeestrat> Hey folks, is it possible to migrate from a deb install of a region/rack controller to a snap install? Didn't see anything in the docs about this. I guess the db will be the hard part.
[12:45] <BlackDex> zeestrat: maybe dump the database, and try to import in into the snapped environment. But i don't know if that is possibl
[12:45] <BlackDex> e
[13:20] <roaksoax> zeestrat: i wouldn't move the DB inside the snap
[13:20] <roaksoax> zeestrat: i would use external db and maas from the snaps
[13:21] <roaksoax> zeestrat: that way you, if in the future you decide to grow multiple regions (HA)
[13:21] <roaksoax> you are not constrained by having the DB inside a single snap
[13:36] <zeestrat> roaksoax: Thanks. That sounds like a good approach.
[15:00] <BlackDex> roaksoax: That is nice indeed. Normally if you install maas it installs the database it self and configures it self. But is this different for the snap?
[15:01] <roaksoax> BlackDex: the snap follows hte ssame principles as in the package
[15:01] <roaksoax> BlackDex: the sanp you tell it how you want to configure it
[15:02] <roaksoax> BlackDex: the same way you can do in MAAS installed by the packages, or as you can do in the snap, is forward it to a external DB
[15:02] <BlackDex> ah oke :)
[15:03] <BlackDex> something to tryout in the future :)
[15:03] <BlackDex> good to know
[17:49] <tych0> hey guys, i'm getting https://paste.ubuntu.com/p/Pzj8ycBrXc/
[17:49] <tych0> is there a way i can find out what the actual issue is? is it ECONNREFUSED, or a self signed cert or something?
[17:52] <mup> Bug #1748875 opened: Unable to deploy Bionic on bare-metals with MaaS 2.3.0 <amd64> <apport-bug> <uec-images> <xenial> <cloud-images:Invalid> <MAAS:Fix Committed by andreserl> <MAAS 2.3:Triaged by andreserl> <maas-images:New> <https://launchpad.net/bugs/1748875>
[17:55] <mup> Bug #1748875 changed: Unable to deploy Bionic on bare-metals with MaaS 2.3.0 <amd64> <apport-bug> <uec-images> <xenial> <cloud-images:Invalid> <MAAS:Invalid by andreserl> <maas-images:Fix Committed> <https://launchpad.net/bugs/1748875>
[18:06] <roaksoax> tych0: that seems that there would be no rack controllers that can power on a machine
[18:06] <roaksoax> tych0: e.g. it cannot directly reach it
[18:06] <roaksoax> tych0: /win 4
[18:06] <roaksoax> err
[18:07] <tych0> roaksoax: ok, but what does that mean? is it ECONNREFUSED? or dns doesn't resolve?
[18:08] <tych0> i can wget the url from the rack controller and i see output i expect
[18:08] <tych0> so i'm not sure what's idfferent from maas' environment
[18:11] <roaksoax> tych0: what power type is it ?
[18:11] <tych0> UCS manager
[18:33] <roaksoax> tych0: could be that there's a bug with the ucs manager power type. Are you using IP or DNS ?
[18:34] <tych0> IP
[18:34] <tych0> it's also possible that i have it pointed at the wrong rest API
[18:35] <tych0> but i don't know how to tell really
[18:35] <roaksoax> tych0: if you are using ssl, then yes, since we dont support ssl for power params
[18:36] <tych0> ah, so i need a http:// url?
[18:37] <tych0> this box gives a 301 to the https:// url :(
[18:39] <roaksoax> tych0: yeah http:// url indeed
[18:41] <tych0> ok, so if it enforces https with a redirect, i'm screwed?
[18:42] <hallyn> ugh
[18:42] <hallyn> is it all simple scripts, can it be easily hacked around/
[19:04] <mup> Bug # changed: 1585841, 1642916, 1702527, 1713771, 1729555, 1730626, 1730751, 1730991, 1733923, 1734347, 1735840, 1738478, 1741574, 1741915, 1742137, 1743005, 1744802
[22:45] <tych0> roaksoax: so i just set up an ssl stripping proxy to try and use maas
[22:45] <tych0> and got,
[22:45] <tych0> Error:__init__() missing 4 required positional arguments: 'code', 'msg', 'hdrs', and 'fp'
[22:46] <tych0> i'm trying to find a full stack trace, but no luck so far
[22:47] <roaksoax> tych0: honestly i wouldn't know at this point, as last time we worked with one of those was a while ago and we dont have one in CI
[22:47] <roaksoax> tych0: maybe ucs has updated their API whjich is causing the breakage ?
[22:48] <tych0> ah, ok
[22:48] <tych0> i guess if it's not in CI then it's probably not going to work :)
[22:49] <tych0> roaksoax: ok, cool, thanks!
[22:50] <hallyn> ok but surely
[22:50] <hallyn> surely there is a way to get more detailed logs about where the %$%$% it's failing
[22:51] <hallyn> tych0: are you able to tell whether it manages to connect to the CIMC and start sending msgs?
[22:51] <hallyn> (i suppsoe maybe tcpdump is the way to go here)
[22:52] <hallyn> (if maas doesn't want to help)
[22:52] <tych0> mitmproxy tells you
[22:54] <hallyn> ah
[22:54] <hallyn> ok so the connection is going through, but it fails while talking?
[22:54] <hallyn> so mitmproxy should be able to dump the text of the conversation right?
[22:54] <tych0> no, it's not going through
[22:54] <roaksoax> tych0: are you pointing maas to their xml api endpoint ?
[22:55] <tych0> (but i can see other connections, for example if i use https, maas will complain about a self signed cert)
[22:55] <tych0> roaksoax: well, i'm pointing it to my ssl stripping proxy, which forwards the request with https on to the actual XML api
[22:56] <roaksoax> tych0: right, but for example, looking at the code I see that we add 'nuova' to the URL
[22:56] <tych0> oh, you guys add that?
[22:56] <roaksoax> tych0: yeah
[22:56] <tych0> i've added it in my url
[22:56] <roaksoax>         self.api_url = urllib.parse.urljoin(self.url, 'nuova')
[22:56] <tych0> i'll remove it and check
[22:57] <hallyn> lol
[22:57] <tych0> yeah, same erorr about __init__() missing 4 required positional arguments: 'code', 'msg', 'hdrs', and 'fp'
[22:58] <hallyn> oh - so is that error being passed by the cimc/ucs back to maas?
[22:58] <hallyn> if so then (a) i guess i see and (b) all is lost
[22:58] <tych0> no
[22:58] <tych0> i think the error is in maas before it ever tries to talk to the cimc
[23:01] <tych0> oh, whee
[23:01] <tych0> got them to talk, now i get
[23:01] <tych0> XML PARSING ERROR: The XML API method configResolveClass, has unrecognized child element(s) in the xml request.
[23:01] <roaksoax> tych0: that seems to me that the xml api could have changed since first enabled
[23:02] <tych0> yeah, that error definitely seems like it
[23:04] <tych0> <configResolveClass classId: "computeItem" cookie="1518620578/db1728c5-652d-152d-8003-e8a41a735d00"><inFilter><eq class="computeItem" property="uuid"
[23:04] <tych0> value="2F5D552B-6BD5-4E2D-9B8B-E707032096FA"/></inFilter></configResolveClass>
[23:04] <tych0> is the thing that it doesn't like parsing.
[23:07] <tych0> oh, no, sorry
[23:07] <tych0> that's the request, derp.
[23:07] <tych0> <error cookie="" response="yes" errorCode="ERR-xml-parse-error" invocationResult="594" errorDescr="XML PARSING ERROR: The XML API method configResolveClass, has unrecognized child
[23:07] <tych0> element(s) in the xml request. " />
[23:07] <tych0> the error is from the cimc itself
[23:07] <tych0> it doesn't like the request maas is sending, i guess?