#maas 2012-06-11
<allenap> matsubara: Hi there, have you just installed python-tempita on the build machine by any chance?
<allenap> matsubara: Ah ha, no, it was rvba. Thanks rvba :)
<matsubara> allenap, I haven't but I can if you need.
<matsubara> :-)
<matsubara> the joys of shared maintenance
<matsubara> btw, I should be able to start the migration from ec2 to the QA lab jenkins instance today
<matsubara> finish with the maza migration as their instance crashed last week and the team is blocked
<allenap> matsubara: Oh cool, nice.
<matsubara> s/finish/finishing/
<allenap> rvba: Interesting failure now; it wants confirmation for deleting the test database. I'll sort it out.
<rvba> allenap: yep, I'm seing this.
<rvba> matsubara: that's great news!
<roaksoax> rvba: howdy! so I was wondering if there are significant changes in maas trunk yet that require new packaging and stuff?
<rvba> allenap: build fixed.  I think there is an option in Django to make the command "make check" non interactive.  This would avoid the problem we just saw.
<rvba> roaksoax: hi.  Well, we've changed the architecture quite a bit since we are working on removing cobbler.
<roaksoax> rvba: ok... is it still functional in trunk? What packaging changes you think it needs? What new dependencies hae been introduced?
<rvba> roaksoax: it is functional, we're removing things bits by bits.
<roaksoax> rvba: ok. On the other hand, what version of libraphael and libyui you guys need as the plan is to remove them from shipping them on trunk
<roaksoax> so we need to ensure the packages are updated accordingly
<rvba> roaksoax: indeed.  I think I'd like to use yui 3.5 (we currently use 3.4.1) but I need to make sure everything is fine with YUI 3.5 first.  I'll do that this week and get back to you.
<roaksoax> rvba: ok, other than that, If I get to that this week, I'll update to yui 3.4.1 and then we can upgrade
<roaksoax> rvba: what about libraphael?
<rvba> roaksoax: we use 2.1.0.
<roaksoax> ok
<roaksoax> i'll take ccare of that
<rvba> roaksoax: again, I'll check if there is not a major release that has been done in the meantime.  I guess it would be more profitable to other people if we ship major milestone version as opposed to just the version we need.
<rvba> roaksoax: cool, I'll test MAAS with YUI 3.5.  Then, once the packaging is done, I'll get able to get rid of the version of YUI that we shipâ¦ that will be a very cleanup.
<roaksoax> indeed
<rvba> roaksoax: I guess it won't be a problem for you to upgrade once the initial packaging will be done right?  It's just a bunch of static files as far as you're concerned I guess.
<rvba> allenap: I've got another branch up for review if you feel like it: https://code.launchpad.net/~rvb/maas/ui-power-parameters/+merge/109621
<rvba> allenap: and then I'll be done with the power parameters \o/
<cheez0r> hrm, i can't figure out if this is a maas issue or a juju issue; I've got 11 nodes in my maas, they're all allocated to me, I've done a juju bootstrap and a bunch of deploys, but some of my machines in juju stay in agent-state: not started; and on the console these nodes get stuck partway through their pxe boot.
<cheez0r> they seem to lock up, with nothing but the pink ncurses background screen showing. A reboot brings them back through the pxe process and they hang at the same spot.
<cheez0r> since it's not making it through pxe I figured I'd talk to you guys first ;)
<cheez0r> The last thing it does is I see it pull the kickstart, then load 'additional components', then NTP, then partitioning, and then it just sits there.
<roaksoax> rvba: yeah raphael and yui shouldn't really be an issue
<roaksoax> cheez0r: those those machines *don't* pxe boot? or they pxe boot but doesn't show up the installer?
<cheez0r> roaksoax: they pxe boot, they load the pxelinux image, they do the initial boot sequence, they do the initial system configuration (network addressing, NTP time, etc)
<rvba> roaksoax: I'm testing with YUI 3.5.1 and everything seems fine.  Also, libraphaeljs 2.1.0 is the most recent release.
<cheez0r> then they hang after partition manager.
<cheez0r> I'm watching the console of one right now: loading additional components: partman, pkgsel, etc. Setting up the clock/NTP; detecting disks; flash; starting up the partitioner, flash, flash, nothing.
<cheez0r> flash = too quick to be read
<roaksoax> rvba: ok cool
<allenap> rvba: Sure, I'll review that.
<roaksoax> cheez0r: is there a way you could get the syslog of the machine being installed?
<rvba> allenap: ta.
<allenap> rvba: Sorry for the delay; someone at the door.
<cheez0r> roaksoax: it never boots to a point where it can be accessed.
<roaksoax> cheez0r: right, but the installer is running, which means it has a ssyslong
<cheez0r> I have been watching cobbler.log; it stalls directly after generating and downloading its kickstart.
<roaksoax> syslong
<rvba> roaksoax: apart from that we've added two new dependencies: python-celery python-tempita
<cheez0r> roaksoax: right, but I can't get to it without being able to log into the system
<roaksoax> rvba: awesome. so it is still using cobbler
<rvba> roaksoax: we will need to update the packaging scripts when we will want to start the celery workers but we need to think about how to do this properly first.
<rvba> roaksoax: yes, right now it does.
<rvba> allenap: hehe, no worries.
<roaksoax> rvba: ok so the first step, I'll provide a new release in quantal with what is in trunk now introducing the new dependencies and filing MIRs
<roaksoax> and then step by step we can be improving the packaging
<roaksoax> rvba: as I'm sure they will be some cleanup to be done
<rvba> roaksoax: if we don't start the celery workers this won't be functional.
<rvba> roaksoax: because the only part that replaces cobbler with our stuff uses celery.
<roaksoax> cheez0r: https://help.ubuntu.com/community/Installation/NetworkConsole
<roaksoax> rvba: right, but right now you said it is using cobler still, so we don't need it yet?
<rvba> roaksoax: like I said, we're replacing it bits by bits.  Most of the application uses it still but the tiny part which does not use it uses celery.
<roaksoax> rvba: alright, I guess i could release a partially working maas in order for me to introduce the new dependencies and get things working
<rvba> roaksoax: if by "partially working" you mean "not really working" then yesâ¦ but I'm not sure it's worth it really.
<roaksoax> rvba: right, but I much rather have all the new dependecies in main now than later
<roaksoax> rvba: how do you usually start celery workers?
<cheez0r> roaksoax: I'm not following what you're telling me to do; are you basically saying create this netboot iso, boot the system with it, log into it, and somehow recover the log from the prior install attempt where it never wrote a partition to a disk, so there can't be any log retained?
<roaksoax> cheez0r: not the netboot ISO. use the network-console part
<roaksoax> cheez0r: it will allow you to login while the installer is running
<cheez0r> okay, so how do I implement this in the pxe boot image file?
<rvba> roaksoax: Very simple: add the maas package to the PYTHONPATH and then run 'celeryd'.
<roaksoax> cheez0r: you only need to modify the preseed file
<cheez0r> ah ok
<roaksoax> cheez0r: /var/lib/cobbler/kickstarts/maas.preseed
<rvba> (note that it also need the rest of the python packages provided by maas but IIRC they will be on the general python path)
<roaksoax> rvba: so is it similar to how we run twistd?
<rvba> roaksoax: in the most simple case yes, but then we want to be able to run the workers on another machine and also run many workers.
<roaksoax> cheez0r: sthis 3 are the ones you need:
<roaksoax> d-i network-console/password           password SECRET123
<roaksoax> d-i network-console/password-again     password SECRET123
<roaksoax> d-i preseed/early_command string anna-install network-console
<rvba> roaksoax: and we haven't started the work for these complex setup yet.
<roaksoax> rvba: right, so as a first step, wouldn't it make more sense to ship a wrapper that sources PYTHONPATH and runs celeryd and/or upstartify it?
<cheez0r> I've already got a partman/early_command string; that can coexist with preseed/early_command string?
<cheez0r> (just confirming)
<roaksoax> rvba: and eventually ship it in i.e. maas-worker
<roaksoax> rvba: and provide a config to say how many workers are needed to be run?
<roaksoax> cheez0r: yes, just add network-console to the end
<rvba> roaksoax: That could be first step indeed. Yeah, the plan is to ship the workers within another package.
<rvba> roaksoax: but this is very much WIP.  Unless you really really want to do a release, I suggest waiting a little bit so that we can think of a plan.
<roaksoax> rvba: awesome then, so we *do* need a wrapper for celeryd or it is just the same way as how twistd was used?
<roaksoax> rvba: well I was talking to Daviey last week and we agreed on having a new release in archives ASAP cause there
<roaksoax> there's much to take care. i.e. New versions of raphael/yui/ File MIR's for celery ., etc etc
<rvba> roaksoax: ok then.  But we definitely will need to iterate on that first release.  You've been warned ;)
<roaksoax> rvba: :) no worries... after what I've dealt with last cycle this is piece of cake now :)
<rvba> roaksoax: haha. What would the wrapper do then?
<roaksoax> rvba: TBH, I rather identify issues and start working on getting things package now than be in trouble later
<roaksoax> rvba: that's my question, do we really need a wrapper that starts as many workers wanted? or for me we can just run celeryd from an upstart job
<rvba> roaksoax: sure.  We're in the middle of reachitecturing the whole thing that's all :)
<rvba> roaksoax: we need only one worker for now.
<roaksoax> rvba: ok, so that means using an upstart job is enough
<rvba> Starting celeryf with the right packages on the path should be enough.
<rvba> celeryd*
<rvba> Yes I think so.
<roaksoax> rvba: cause, once we need various workers, we can just have a wrapper that starts as many as cfonfigured and replace it with the upstart job
<roaksoax> s/with the upstart job/within the upstart job
<rvba> Well, it will be more complicated than that because how many workers to start is an information that will be in the DB so starting workers and stuff will need to be done at the application level.  Or at least controlled at the application level.
<rvba> But let's start with the simple case.
<cheez0r> roaksoax: similar behavior- I connect to the network console, I start the install, it finishes with setting up the partition manager, it kicks me out of the network console.
<rvba> roaksoax: so, you need to start celeryd with all maas' packages available on the path, plus the celery configuration file (etc/celeryconfig.py).
<cheez0r> now ssh back in no longer works, but the console is still stuck on "Continue installation remotely using SSH" screen
<roaksoax> rvba: ok, awesome. As always I'll seek your advice when I get to that part
<rvba> allenap: I'm thinking that if we want to do the massive code reorg we talked about the other day, we should probably do that ASAP.
<rvba> roaksoax: sure, no problem.
<roaksoax> cheez0r: uhmmm
<roaksoax> cheez0r: TBH I hjave no idea what it could be
<cheez0r> k
<roaksoax> cheez0r: smoser` Daviey ^^ any ideas for cheez0r's issue?
<allenap> rvba: I'm losing interest in that because of the Django app issue :-/ Do you want to try moving metadataserver to maas.metadata (or something like that)? If you can get that to work then I think we're back on.
<rvba> allenap: I can try that.  What was the issue?
<rvba> allenap: if we don't manage to pull it off then I think we should at the very least rename 'apiclient'.
<allenap> rvba: Django complained that it couldn't load the app, but it didn't make a lot of sense. I suspect a bug.
<rvba> allenap: ok, I'll see what I can do.
<allenap> CoolÂ·
<cheez0r> roaksoax: so I ran the network connection as a shell and continued the installer on the console, and tailed syslog
<cheez0r> I've got the output of that if you'd like it- it appears to be querying memory modules and CPUs and then just dies
<cheez0r> the last line I get is kernel: [ ###.######] lowmem_reserve{}: 0 869 64806 64806 and then the beginning of another line before "Connection closed by remote host."
<roaksoax> cheez0r: so that might be a kernel issue with your hardware? or faulty hardware even?
<cheez0r> could be; all of the blades in this chassis are identical though, so hardware maybe, and it's passing all of the on boot/POST tests
<cheez0r> I'm also getting this issue on five of eleven blades
<cheez0r> I'm checking hardware configuration right now to try and isolate differences
<roaksoax> alright!/win 3
<allenap> Diff against target: 4466764 lines (+3848606/-587797) 5320 files modified  <-- rvba does not muck around.
<rvba> allenap: haha :).  I look forward to removing YUI our tree.
<rvba> from* our tree
<roaksoax> rvba: still around?
<marcoceppi_> So, as I continue to venture into a more stable BTRFS setup, I've been trying to research if USB3 is just as bad as USB2 for connecting disks over long periods of time. Is USB3 any better than USB2 in regards to consistency of disk connections? Or should I still be hunting for a better method of connection not using USB at all
<marcoceppi_> FUUUU, wrong room
<kurt_> General help question:  I'm having difficulty getting a node to accept an ssh key and allow auto-logon.  Other nodes don't have this problem.  I've tried deleting and re-adding the node via maas, and the node re-bootstraps, but still no go with the key.  Any suggestions?
<kurt_> Anyone watch this list? :)
<kurt_> General help question:  I'm having difficulty getting a node to accept an ssh key and allow auto-logon.  Other nodes don't have this problem.  I've tried deleting and re-adding the node via maas, and the node re-bootstraps, but still no go with the key.  Any suggestions?
#maas 2012-06-12
<bigjools> is its clock out of sync?
<kurt_> Hi - question on this - I see an ntpd check
<kurt_> Julian, right?
<kurt_> so, would there be a way to force a check to ntpd to admin node, or make that an option?
<kurt_> I have seen that bug you guys had out there
<bigjools> well if the clock is out of whack and ntp fails for some reason then oauth  fails, which is required to access the metadata service on boot
<bigjools> just set the hardware clock for now until there's a better solution for this
<kurt_> so, will bios clock take care of that?
<kurt_> this is all in vmware in case you couldn't guess
<bigjools> ah
<kurt_> is that an "ah" with a big stamp of disapproval? :)
<bigjools> check the console when it's booting up for the first time then, if it sits waiting for a long time then it's probably the oauth/clock thing
<kurt_> ok, I can try that
<bigjools> but yes I'd have thought the clock time would come from the host
<kurt_> clock time was definitely way off
<kurt_> 14 hours
<kurt_> do I need to do something after that to force a bootstrap of the node then?
<kurt_> still asking for password
<kurt_> I was reading about clicking on start button from MAAS interface?
<bigjools> are you using juju?
<kurt_> yup
<bigjools> you don't need to use the maas interface to start then
<bigjools> and juju passes the ssh key
<kurt_> since that doesn't appear to be working, how do I get the node to re-sync the ssh key?
<kurt_> juju bootstrap, again?
<bigjools> yes
<kurt_> I've been trying that without much luck...
<bigjools> destroy the juju env
<kurt_> eeek
<bigjools> fix the clock
<bigjools> bootstrap again
<kurt_> :)
<bigjools> well if it's not a node with the master on it then you can just release it
<kurt_> do I not need to use maas when using juju?  I'm still learning this stuff
<bigjools> juju works with many providers :)
<bigjools> it's up to you if you want to use maas
<kurt_> if I want to do things in my own private cloud, then maas is the only way, right?
<bigjools> but for local deployments maas is good
<kurt_> ok, cool
<bigjools> it's still a bit rough around the edges
<kurt_> :) you guys are working throught
<kurt_> through it
<bigjools> we try :)
<kurt_> my purpose is create a private cloud so I can try a third party enterprise cloud management system called convirture
<kurt_> not sure if you are familiar with it
<bigjools> I'm not
<kurt_> they have a community version AND enterprise version
<kurt_> does the name xen-man ring a bell?
<kurt_> in any case, I'm really trying to get a private cloud going to test convirture.  I'm thinking juju may be redundant for my needs
<roaksoax> rvba: howdy
<rvba> roaksoax: \o
<roaksoax> rvba: so I have raphael and yui packaged
<rvba> roaksoax: \o/
<roaksoax> rvba: in ppa:maas-maintainers/testing for quantal
<roaksoax> rvba: so feel free to start the migration :)
<roaksoax> and ttest those packages
<rvba> roaksoax: meanwhile I've upgraded the YUI version we use in maas to 3.5.  All good.
<roaksoax> rvba: awesome! I was looking into doing it myself blast night but there's some thing i obviously don't know about so I didn't :)
<rvba> roaksoax: it was really simple for me to upgrade.  And I was ready to fix issues/deprecations etc but it turns out all went smoothly.
<roaksoax> rvba: awesome, so we should be able to use the packages failry easily then
<rvba> roaksoax: I just need to make sure the structure plays well with 'combo' (the component we use for loading tons of js files in one request.
<rvba> The structure of the files in the package that is.
<roaksoax> rvba: yeah I think changes are gonna be needed in order to access that directory, aren't they? i/e/ tdeal with permissions and stuff
<rvba> roaksoax: I assume the directory where the files will end up will be readable by anyone right?
<roaksoax> rvba: can't recall but it is /usr/share/javascript
<rvba> I just installed the package (on precise), seems ok.
<rvba> roaksoax: will the package end up in precise at some point?
<roaksoax> rvba: I guess we'll have to backport it
<roaksoax> rvba: would you rather have a precise version to test against?
<rvba> roaksoax: well, the version you gave me installed just fine on precise.  It's just a bunch of dead JS files after all :).
<rvba> roaksoax: the package as it is won't play nice with the way the combo loader works.  Because the typical requested path looks like this: /combo/?3.5.1/build/overlay/assets/skins/sam/overlay.css&3.5.1/build/w...
<roaksoax> rvba: yeah, providing a precise version is simple enough as building it for precise
<rvba> roaksoax: we obviously can strip out the "3.5.1/build" from each path but it would be much more simple if the file path could match this.
<roaksoax> rvba: ok hold on, you say you *don't* want 3.5.1/build in the path?
<rvba> roaksoax: I *do* want it.
<rvba> roaksoax: Let me give you an example.
<roaksoax> rvba: ok, so i guess it could be done
<roaksoax> rvba: however, I do not want ot change howthis is done in distros
<roaksoax> i.e. maybe policy says *not* to do that
<rvba> roaksoax: I'm just telling you what would be more convenient for us.  You get to tell me if it's possible or not :).
<roaksoax> rvba: let me try to see if there'
<roaksoax> s some kind of policy
<rvba> So, long story short, YUI3 has this built-in tool to load multiple js/css file all in one request.
<roaksoax> rvba: eitherway, I do not want to differ that much from debian
<rvba> It's very convenient because on the JS side you simply load modules and the a single request loads all the JS files in one request.
<rvba> But it requires a component on the server side to parse the request and return the (concatenated) files.
<rvba> In the Django world this component this component is called 'convoy'.
<rvba> Yahoo also provide a service that does serve these files but you have to use their servers in that case and we (in MAAS) can't do that.
<rvba> Convoy works by being pointed to a root directory and serving up files from there.
<rvba> But the structure needs to be {yui_version}/build/JS_files_from_the_release
<rvba> Right now /usr/share/javascript/yui contains all the JS files from the release.
<rvba> roaksoax: Having a symblink from /usr/share/javascript/yui/3.5.1/build pointing to /usr/share/javascript/yui could do the trick.
<roaksoax> rvba: right. So yes, let me check wehther policy mentions something about that, as if I do a change like that, it might affect many other things
<roaksoax> rvba: i'd rather have a symlink in //usr/share/maas/web/static
<rvba> Another benefit of this whole combo thing is the ability to use multiple versions.  With the current structure of the package we would somewhat lose that possibility.
<rvba> roaksoax: yeah, that would be fine.  We just need to be able to access, say model.js from {YUI_ROOT}/3.5.1/build/model/model.js
<rvba> roaksoax: this is very YUI specific so I doubt you'll find something related to this.
<rvba> roaksoax: I think the symblink should be somewhere in the YUI package if possible.  This way convoy + libjs-yui would be fully reusable outside of MAAS.
<roaksoax> rvba: http://wiki.debian.org/Javascript/Policy
 * roaksoax BRB
<roaksoax> rvba: ok, so the policy doesn't mention anything about the versioning
<roaksoax> so symlinking might be a good thing. I'm going to try to see if I get an answer from anyone on that team or with better experience packaging javascript
<rvba> Cool, thanks for going that roaksoax.
<rvba> s/going/doing/
<adam_g> how does MAAS provide file storage for the Juju provider?
<ahasenack> does maas provide a metadata service like aws?
#maas 2012-06-13
<jtv> bigjools: could you sanity-check my updated tftp directory layout at the bottom of this document?  https://docs.google.com/a/canonical.com/document/d/1lpaxXmABGz7ytfc7TrXHCwin7B08EJBEHVyG92KO2qw/edit#
<bigjools> jtv: yup
<jtv> Thanks.
<bigjools> jtv: we have a call shortly, we can discuss?
<jtv> Yes
<bigjools> jtv: ok waiting for you on skype
<jtv> Coming
<bigjools> *cobblerrage*
<bigjools> jtv: have you seen cobbler just suddenly decide to stop authenticating on the web ui?
<bigjools> the log says:
<bigjools> Wed Jun 13 05:39:20 2012 - INFO | REMOTE invalid token; user(???)
<jtv> bigjools: you get that exact authentication failure if your token has expired â or for any other kind of problem with the token IIRC.
<bigjools> jtv: yes I know, but I am logging in to the web ...
<jtv> Ah
<Daviey> rbasak: Hey, jtc mentioned that you said pxelinux.cfg/default cannot be customised for different architectures
<Daviey> I'm missing your concern.
<Daviey> jtv*
<rbasak> You need to serve a different pxelinux.cfg/default for each architecture, eg. by having different pxelinux.cfg directories
<rbasak> Otherwise you'll end up serving the wrong arch kernel
<jtv> Hi rbasak
<rbasak> Hello!
<rbasak> Does that make sense?
<Daviey> rbasak: I thought we were looking to make them arch named?
<rbasak> You could for example have pxelinux.cfg/amd64/default and pxelinux.cfg/armhf/highbank/default
<rbasak> Set DHCP "filename" to pxelinux.cfg/amd64/pxelinux.0
<rbasak> Or pxelinux.cfg/armhf/highbank/pxelinux.0 if the highbank vendor string is detected
<rbasak> But the default files need to be distinct, and pointed to by the dirname part of the DHCP filename entry
<Daviey> rbasak: hwhat is wrong with dhcp 209?
<jtv> Isn't pxelinux.cfg assumed to be in the same directory as the DHCP filename?
<rbasak> Yes, exactly
<rbasak> Daviey: dhcp 209: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/927781/comments/2
<ubot5`> Ubuntu bug 927781 in u-boot-linaro (Ubuntu) "PXELINUX implementation doesn't respect dhcp ConfigFile or PathPrefix values" [Undecided,In progress]
<rbasak> Daviey: ie. no dhcp 209
<Daviey> rbasak: 209 = pxelinux.cfg/default-armhf-highbank ?
<Daviey> rbasak: i thought we were getting that bug fixed
<rbasak> Daviey: AIUI, it's a wontfix because the feature is already supported via the filename dirname
<rbasak> Justin did implement the 209 feature, but I don't think it went anywhere after that
<Daviey> rbasak: before Justin left, he wrote a patch for 209
<Daviey> hah
<rbasak> jhobbs pointed out in comment 2 that the existing support is sufficient
<rbasak> It's just a question of how we arrange the pxelinux.cfg directory
<rbasak> And this is only really necessary for the default files
<rbasak> You could for example only serve a subarchdirectory filename entry for unknown MACs, and for known MACs just make the MAC-based config file correct for the architecture that we know it is
<rbasak> Assuming that we know the architecture as soon as we know the MAC
<Daviey> well default file handling is a PITA
<Daviey> we'd need /var/lib/tftpboot/pxelinux.cfg/$arch/$flavour/default
<rbasak> It isn't nice, but getting U-Boot support for 209 into every vendor firmware isn't really practical AFAICT
<Daviey> rbasak: can you investigate if we can at least get that patch in trunk?
<rbasak> That's a pretty big task to pick up
<rbasak> I didn't even write the patch remember
<rbasak> I'm not sure it's worth it given our current priorities
<Daviey> rbasak: Yeah, i asked Justin to write the patch.. but i suspect he won't follow through with it now :)
<Daviey> rbasak: current priority is pretty clear from #8.. we are still doing it wrong.
<rbasak> I think we need to assume that the patch won't be present in vendor firmwares
<jtv> If it helps, the question that's blocking us now is what would be a sensible directory structure for the files we need to serve on tftp.
<rbasak> I'm not sure I understand what #8 means
<Daviey> rbasak: it's a big task to submita pull request for this patch?
<rbasak> We need to have a different kernel for every subarch
<rbasak> Daviey: it's a big task to follow it through and potentially fix future bugs found in relation to the patch
<Daviey> ok, fine, i'll just do it myself.
<rbasak> If we need to have a different kernel for every subarch, we need to have a mapping from vendor class identifiers to our subarch names
<rbasak> The mapping is within each default file
<rbasak> Apart from the specific paths in use, I don't see how we could do it differently
<rbasak> jtv: I think a sensible directory structure would be:
<rbasak> pxelinux.cfg/amd64/{pxelinux.0,default}
<rbasak> pxelinux.cfg/armhf/{armadaxp,highbank}/default
<rbasak> pxelinux.cfg/combined/<mac>
<rbasak> or if you don't like combined, just put each <mac> entry in the correct arch/subarch directory
<jtv> Actually I wasn't expecting to be able to rearrange things inside the pxelinux.cfg directoryâ¦ how do we tell clients what to look for in there?
<rbasak> They look for their mac address in the directory that pxelinux.0 came from, which is specified by the DHCP filename field
<jtv> So pxelinux.0 is inside the pxelinux.cfg?
<rbasak> Oh, good point
<jtv> (Stupid perpetual unity crashesâ¦)
<rbasak> I'm wrong. The pxelinux.cfg directory is expected to be in the same directory as pxelinux.0
<jtv> That's what I thought.
<rbasak> Let me try again
<jtv> Have a look at the updated google doc.
<rbasak> amd64/pxelinux.0
<jtv> https://docs.google.com/a/canonical.com/document/d/1lpaxXmABGz7ytfc7TrXHCwin7B08EJBEHVyG92KO2qw/edit#
<jtv> Near the bottom
<rbasak> amd64/pxelinux.cfg/default
<rbasak> armhf/{armadaxp,highbank}/pxelinux.cfg/default
<jtv> The examples in the doc don't include release name yet though.
<jtv> rbasak: the example you give is included there
<jtv> ISTM we can create subdirectories for the initrds and kernels per release, and keep everything else as in the doc?
 * jtv fiddles
<jtv> There.  That's assuming that a node's specific config file will contain a reference to the right initrd/kernel, with its path.
<jtv> Ooo, comments are flowing.  Thanks Robie.
<rbasak> jtv, Daviey: would a quick G+ be worth it? I think it's important we get this right, I haven't made any mistakes and we're all clear on how this wil work :)
<jtv> Sure.
<jtv> Who wants to set up a hangout?
 * rbasak does one
<rbasak> Daviey: ?
<Daviey> rbasak: I think 209 is the /right/ fix TBH
<rbasak> Daviey: I agree, but I'm being pragmatic. It's never gonna happen.
<rbasak> Since some vendors will never have caught up
<Daviey> rbasak: you know we are stakeholders in defining this stuff, right?
<Daviey> rbasak: we may well need to chainload into 'someting smarter' regardless.. Depending on embedded firmware for anything is a limitation we need to be careful folding into.
<jtv> Daviey: coming into the hangout?
<rbasak> Daviey: can you join our G+?
<kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
#maas 2012-06-14
<kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
<kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
<bigjools> kurt_: yes, 2 ways
<bigjools> 1. juju does it for you if you use juju
<bigjools> 2. you need to register them in maas against your maas user
<bigjools> if you start a node manually use #2
<kurt_> is this mostly done by maas, or juju?
<kurt_> so, create your key, configure it in the settings, right?
<bigjools> kurt_: is what done?
<bigjools> if you are using juju you don't need to worry about it
<kurt_> I guess I wondering what mechanism/script does a chroot and copies the key in your home directory to the image that gets booted?
<bigjools> it gets passed via preseed data
<kurt_> because, even though my clocks are all relatively up to date, I am having trouble with one or two servers booting
<kurt_> (these are VMs again, remember)
<bigjools> watch the console log when the VM boots
<bigjools> it should give some info
<kurt_> maas.log or the VM's console? (ie. dmesg or syslog/messages)?
<bigjools> VM console
<kurt_> kk - how does server/VM force a reseed of the pre seeded software? is there some way to force this?
<kurt_> presided data rathere
<kurt_> preseeded data rather
<bigjools> kurt_: http://pastebin.ubuntu.com/1040179/
<kurt_> thnx Julian
<bigjools> np
<kurt_> can you tell me when the next full release is scheduled vs git releases?
<bigjools> you mean bzr? we don't use git
<kurt_> apt-get update maas :)
<bigjools> there's a point release scheduled with 12.04.01
<bigjools> and it'll run without cobbler
<kurt_> kk - are you guys looking at forcing delete even when node is in state "commissioning" or will that always be left to the shell?
<bigjools> that's fixed in trunk already
<kurt_> cool, nice to have
<kurt_> will shell features be more completely documented? :)
<bigjools> unlikely
<kurt_> I've been learning what I know via newsgroups
<kurt_> or postings
<bigjools> they are for developer and debug usage
<bigjools> we'll document supported stuff for sure
<bigjools> but people are free to document unsupported stuff themselves :)
<kurt_> If I can figure it out, I'm happy to ;)
<kurt_> Like the section on the non-dhcp set up of maas :)
<bigjools> that's not supported yet
<kurt_> that will be really nice to have
<bigjools> presuming you mean external dhcp
<kurt_> I do
<bigjools> it's not really something that we're concentrating on because it makes things much harder to use
<kurt_> understood - get things working first
<kurt_> get it solid
<bigjools> well, the dhcp actions are integral to how maas operates
<kurt_> yes!
<bigjools> we're moving all this out of cobbler and into maas at the moment
<bigjools> so when maas does it itself it should be  more obvious how to set it up manually
<kurt_> because of the pxe stuff, this very much reminds me of clonezilla too
<kurt_> a question about the documented system requirements - are those pretty strict?
<kurt_> ie. 16 GB for the master node?
<bigjools> I'm not sure, but it largely depends on the size of your cloud
<bigjools> I am debugging locally on a 4GB box
<kurt_> for testing and demo purposes, I'm just trying to put together a minimal functional installation
<bigjools> which has a master and a few VMs running on it.  Admittedly it gets sluggish :)
<kurt_> I don't care about performance at this point
<kurt_> but what about the requirement of 9 nodes for openstack?
<kurt_> is that strict, or just a "suggested" number?
<bigjools> I don't know much about that
<kurt_> my end goal is to get a functional openstack installation working
<bigjools> ok
<bigjools> we'd love to help
<kurt_> ie. on top of maas
<kurt_> and juju
<bigjools> when are you normally around on IRC?
<kurt_> I'm GMT -8 (PST)
<kurt_> I'm on all day mostly
<bigjools> ok - there are people who know more intricaces of the server stuff than me who are in -5
<kurt_> and I am happy to contribute to the documentation and such
<bigjools> cool
<kurt_> this is great stuff you guys are doing btw
<bigjools> I'm in GMT+10 so barely overlap with anyone
<bigjools> glad you like it
<bigjools> it's still a little raw but there's some cool stuff coming
<kurt_> so you are a core developer, how many others?  Are you employees of canonical?
<bigjools> yeah, there's me and 3 others working on the core web app
<bigjools> and a few others doing packaging and server stuff
<kurt_> are you dedicated, ie. full time on this?
<bigjools> yup
<kurt_> nice.
<kurt_> I take it you are in austrailia or asia?
<bigjools> yeah Brisbane
<kurt_> excellent
<kurt_> I almost went to work for a contract with Telstra a few years back
<kurt_> my wife put the brakes on that :(
<kurt_> did I see above you guys are trying to get rid of cobbler out of the equation?
<bigjools> we are
<kurt_> I think the more you can streamline this, the better
<bigjools> cobbler is pretty horrible; the security team dislikes it and we don't think it will scale
<kurt_> are you beginning to think of how things can scale in much larger deployments?
<bigjools> not just beginning, it was a core goal
<kurt_> what processes are the best candidates for scaling?
<bigjools> not sure I understand
<kurt_> scaling = spreading the love
<bigjools> what do you mean by processes?
<kurt_> for example maas-dhcp, which configures...
<kurt_> trying to think of the dhcpd process used
<bigjools> there are two :)
<bigjools> dnsmasq or isc-dhcpd
<kurt_> dnsmasq is what I was thinking of...
<bigjools> we're not supporting dnsmasq when cobbler has gone
<kurt_> what will take that function over/
<kurt_> ?
<bigjools> the other one :)
<bigjools> it's more proven in large environments
<kurt_> will it be capable of perhaps supporting VLANs?
<kurt_> multiple large scale VLANs?
<bigjools> vlans are orthogonal really
<bigjools> network admins are free to set any topology
<bigjools> we're just providing a worker on a per-subnet basis
<kurt_> what kind of api's are you guys thinkng of?
<bigjools> the existing API won't change much
<kurt_> ok, I've bothered you enough tonight :)
<kurt_> lol
<bigjools> heh np
<kurt_> thanks for fielding my questions...
<bigjools> my pleasure
<kurt_> I'll look forward to your releases
<kurt_> bfn
<bigjools> we look forward to you trying them out
<kurt_> I'll be happy to give input
<kurt_> what is your suggestion when clock is in sync, and VM gets stuck in "init: cloud-init-nonet main process (307) killed by TERM signal"?
<kurt_> this has been killing me with only one of my VMs
<kurt_> I've tried recreating the mac address, destroying and recreating the VM numerous times
<kurt_> I have to manually delete the name via the maas sheel
<kurt_> shell rather
<kurt_> but always gets stuck in commissioning with that above problem
<bigjools> that's rather odd
<bigjools> is there no other clue as to why the SIGTERM happens?
<kurt_> since I can't get access to the VM until its booted, I'm limited in what I can see
<kurt_> I usually hard power the VM down
<kurt_> is there some mapping associated with the naming?
<kurt_> ie. my hosts name is maas02
<bigjools> smoser or roaksoax, are you guys around? Any idea with the above?
<kurt_> so is some key in the db maybe not being deleted and some artifact in the db remains that's being recycled?
<kurt_> or some cobbler files that the maas shell doesn't delete that need to be manually deleted?
<bigjools> what does cobbler think about the node's power details?
<kurt_> can you tell me how to look?
<kurt_> sorryâ¦not cobbler saavy
<bigjools> well it's turning it on so it's probably ok
<kurt_> its not
<kurt_> I have to manually boot
<bigjools> aha
<kurt_> vmware doesn't really support WOL
<bigjools> well you can manually set the virsh parameters in cobbler
<bigjools> it's not really supported but it'll work
<kurt_> virsh = kvm, not vmware, right?
<bigjools> vmware should work too
<bigjools> not tried it personally
<kurt_> is there some rtfm I can do around this?
<bigjools> browse to localhost/cobbler_web
<kurt_> Not Found
<kurt_> The requested URL /cobbler_web was not found on this server.
<kurt_> must it be on the local node?
<bigjools> no it's on the maas server
<bigjools> ummm different port
 * bigjools tries to remember
<bigjools> 8080?
<kurt_> nope :)
<kurt_> you have 64943 more tries ;)
<bigjools> heh
<bigjools> hmmmm it's possible that the web part is not installed
<bigjools> you'd have to dink about in the command line
<bigjools> there's an exe called "cobbler"
<bigjools> it sounds like the cobbler DB is out of whack with maas anyway
<kurt_> that sounds logical
<kurt_> is there a sync process?
<bigjools> the only way I know of fixing it is to delete the nodes on both sides
<kurt_> how do I fully delete the node on the cobbler side? I think I know how to on the maas side
<bigjools> you can sync manually but it's error prone
<bigjools> via the cobbler web or command liner
<kurt_> do I need to install the cobbler web application?
<kurt_> and why do you guy want to get rid of cobbler?  Its so easy and painless?
<kurt_> LOL!
<bigjools> heh
<kurt_> what are your timelines for getting rid of cobbler?
<bigjools> ASAP
<bigjools> couple of weeks
<kurt_> so, if I begin to install cobbler-common, etc - is that going to overwrite some of the maas related configuration?
<bigjools> yes
<kurt_> ugh
<bigjools> the packages conflict
<kurt_> :)
<kurt_> looks like I'm not going to be able to install cobbler-web
<bigjools> fraid not
<bigjools> the way I get around it is to install cobbler on a separate VM
<bigjools> and point maas at it
<kurt_> otherwise, I need to figure out the command line stuff, right?
<kurt_> do any of your comrades have a better understanding of this part?
<kurt_> I do see the problematic node is listed 3x:
<kurt_> ituser@maas01:~$ sudo cobbler system list
<kurt_>    default
<kurt_>    node-2e11a386-b5c1-11e1-8715-000c29de71df
<kurt_>    node-dc7aa15e-b5ce-11e1-8715-000c29de71df
<kurt_>    node-ff6a0be4-b5d5-11e1-8b34-000c29de71df
<bigjools> ah nice
<bigjools> delete everything and re-add it
<kurt_> I think I've tried thatâ¦but I'll try again
<bigjools> make sure it's deleted in cobbler
<kurt_> so, just do cobbler system remove --name=xxx for all, then relist the systems as shown above?
<kurt_> or is there some other sync too?
<kurt_> or other place in cobbler it needs to be deleted?
<bigjools> remove in maas and cobbler
<bigjools> make sure you do a cobbler sync
<bigjools> as in the command "cobbler sync"
<kurt_> ah, ok
<kurt_> what is the difference between "cobbler sync" and "maas-import-isos" ?
<bigjools> the former tells cobbler to sync its internal database
<bigjools> the latter is the script that pulls the images from maas.ubuntu.com
<kurt_> they look very similar in their functions
<kurt_> i.e.,after images are downloaded
<kurt_> maybe maas-import-isos does a cobbler sync as a part of its functions?
<bigjools> it does
<kurt_> k, I've managed to screw something up now.  web process is stuck.
<kurt_> I removed all of those extra cobbler systems, but it somehow had an association with the newer mac adds associated with maas02
<kurt_> so when I went to try to remove that via the web interface, things went south
<kurt_> ah, like windows.  rebooting fixed everything :)
<kurt_>   File "/usr/lib/python2.7/dist-packages/maasserver/provisioning.py", line 254, in __call__
<kurt_>     raise friendly_fault
<kurt_> ExternalComponentException: Unable to reach provisioning server.
<kurt_> looks like there is artifact in maas db
<kurt_> will try to reprovision to see if that fixes...
<kurt_> ok, discovered issueâ¦ note to self - ensure you have a complete os and system writable disk before proceeding with netboot
<bigjools> heh
<kurt_> configuration couldn't write to vm's disk
<kurt_> so process when creating maas VMs is to build your VM first with complete install, then switch VM to PXE boot.
<bigjools> glad it works
<kurt_> me too. so far so good
<bigjools> I just got powering on with virsh working without cobbler too, so it's all going well today
<kurt_> nice
<kurt_> is that some that works in the current build?
<bigjools> no
<kurt_> ok, something to look forward too :)
<kurt_> ah - ok, I see - cobbler is a lot of the reason you need to do that...
<kurt_> it has the PXE functionality you need
<jtv> bigjools: here
<bigjools> o/
<bigjools> ok
<jtv> Doesn't something in there block until at least the files have been gathered?
<bigjools> no idea
<bigjools> I'll find out shortly
<jtv> I hope it's not the code that (AFAICT) decides to deal with umount failure by doing the umount again.
<bigjools> grepping for "import" doesn't help ....
<jtv> Oh, I'm sure the right answer will be in the output.
<jtv> Somewhere.
 * bigjools stabs a pin in
<kurt_> qq:  can the hostname be changed in the maas interface without repercussion after the hostname has already been created like "node-000c25abcc"?
<jtv> kurt_: the code for maas itself doesn't care, but something else that maas relies on might.
<jtv> Not very helpful, I know.
<kurt_> :)
<kurt_> ok, best to leave it alone
<jtv> Specifically, if it's okay with juju and with cobbler, it should be okay.
<jtv> MAAS in its current incarnation (which still uses cobbler) propagates such changes to cobbler immediately.  But we're on the cusp of radical change.
<kurt_> that's a wee bit of a frustrating part of that interface is having to maintain my own mac adds to human friendly name mapping, esp where VMs are concerned
<jtv> You can leave the hostname blank.
<jtv> I'd assign it only in cases where the hostname has a special meaning to what you're doing.
<kurt_> and yes, je was talking about the whole rework of the cobbler stuff
<kurt_> that's great work
<jtv> Where âeasy workâ would be preferred, of course.  :)
<kurt_> go for the low hanging fruit of course...
<jtv> bigjools: looks to me like cobbler's import_tree rsyncs the whole given directory into its own storage.
<bigjools> jtv: yeah just looking at it
<jtv> Not too surprising, really, given how tiny the two files we want are compared to the whole image we download
<bigjools> nice of it to say "importing from a network location" regardless
<bigjools> bare excepts.... yegads
<jtv> More detail in modules/manage_import_debian_ubuntu.py â with just a hint of suspicion that we've got several layers of scripts and code duplicating similar support functionality.
<bigjools> yup
<jtv> This is going to drive me to drink.
<bigjools> at least you'll be sober in the morning
<bigjools> the code will still be shit
<kurt_> ok, last question of the nightâ¦then off to bed...
<kurt_> trying to delete a node from maas, seeing "Unable to reach provisioning server."
<kurt_> restarted pserv
<kurt_> no joy
<kurt_> any ideas?
<bigjools> what's in the pserv log?
<kurt_> here's little excerpt from maas.log, will get pserv
 * jtv braves the 30â40kg dog in a desperate dash to the bathroom
<kurt_>   File "/usr/lib/python2.7/dist-packages/maasserver/provisioning.py", line 254, in __call__
<kurt_>     raise friendly_fault
<kurt_> ExternalComponentException: Unable to reach provisioning server.
<kurt_> not really much..
<kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] 127.0.0.1 - - [14/Jun/2012:07:38:35 +0000] "POST /api HTTP/1.1" 200 1265 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
<kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] 127.0.0.1 - - [14/Jun/2012:07:38:35 +0000] "POST /api HTTP/1.1" 200 1265 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
<kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] Stopping factory <twisted.web.xmlrpc._QueryFactory instance at 0x2ad9320>
<kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] Stopping factory <twisted.web.xmlrpc._QueryFactory instance at 0x2ad9320>
<kurt_> ok, completely knackered
<kurt_> see you guys tomorrow
<jtv> kurt_: that's the maas log
<bigjools> not much to go on
<jtv> as distinct from the pserv log
<kurt_> last bit is pserv.log
<kurt_> guess I need to turn up debug
<jtv> Sounds as if the maasserver really can't reach the pserver then
<jtv> Try a ps -ef | grep pserv?
<jtv> See if it's really running or not
<kurt_> ituser@maas01:~$ ps -ef | grep pserv
<kurt_> maas     15396     1  0 00:35 ?        00:00:00 /usr/bin/python /usr/bin/twistd -n --uid=maas --gid=maas --pidfile=/run/maas-pserv.pid --logfile=/dev/null maas-pserv --config-file=/etc/maas/pserv.yaml
<jtv> Love that --logfile option
<kurt_> interesting...
<kurt_> default - is that set in pserv.yaml?
<jtv> No idea tbh
<bigjools> jtv: so import looking for repos, kickstarts and bootloaders
<kurt_> ok, good night
<jtv> nn kurt_
<bigjools> nn
<kurt_> can't focus any more
<jtv> then don't overdo it :)
<kurt_> thnx guys
<bigjools> jtv: I think we need more help from server guys
<bigjools> and get their take on what needs doing
<jtv> Can't disagree with you.
<bigjools> yay, late night for me
<jtv> So sorry about that.  :(  I've been trying to throw extra hours at this, but haven't had the energy lately.
<jtv> It does look as if the core of the Cobbler import code looks for initrds and kernels.
<jtv> But it's all much more OS-agnostic, of course.
<bigjools> yeah
<bigjools> but there's then these layers of bash
<jtv> Suddenly the name makes sense to me.
<jtv> bigjools: I've updated the Questions section of the google doc.
<bigjools> ok
<jtv> bigjools: we'll also want to deal with updates that happen concurrently to net-boots.
<jtv> In other words, we can't just replace an initrd/kernel pair while nodes are using it.
<bigjools> depends if tftp keeps a file handle open? :)
<jtv> So we may need to number versions.  The server guys suggested something like this, but I cut it short since it wasn't part of the immediate problem.
<jtv> Bear in mind that it's stateless, UDP.
<jtv> There's no such thing as an ongoing session or even an ongoing download.  A request for a chunk of file comes in and gets serviced, and total amnesia follows.
<jtv> At least conceptually â optimization may be a different issue.
<bigjools> I've no idea how it works internally
<bigjools> anyway
<bigjools> dinner, back later
<jtv> bon appÃ©tit
<jtv> hi there mrevell
<mrevell> Hello jtv
<cheez0r> hey maas gurus, is there a command line way of adding/deleting nodes from a maas?
<cheez0r> the command 'maas' on the command line gives me a number of options but not many seem specific to maas
<rvba> cheez0r: http://paste.ubuntu.com/1040776/
<cheez0r> right, that does the delete
<rvba> To create a node manually: Node(hostname='sss', status=3)  note that you will need to know the internals a bit to provide the right parameters to the node creation method.
<rvba> node = Node(...)
<rvba> node.save()
<cheez0r> can I do node = Node.objects.get(hostname='myhostname')
<cheez0r> node.show()
<cheez0r> ?
<cheez0r> node.print()?
<cheez0r> trying to figure out how to get an existing node out to use as template
<rvba> node.__dict__
<cheez0r> danke
<rvba> I don't know your constraints but note that you would probably be better off using the API.
<cheez0r> just trying to come up with a way to create a file that has mac,arch,hostname and can reproduce what I'm doing in the web gui
<cheez0r> kind of slow to add eleven nodes via the GUI when I'm adding/removing them a lot
<cheez0r> plus for auto-commissioning of a maas cluster that'd be useful
<cheez0r> if I was more of a programmer Id just write a command-line front end to the API, but I'm not much of one :p
<rvba> That's something that's on our TODO list.
<cheez0r> I'm sure, now that I think about it.
<rvba> roaksoax: The fix to support fetching YUI's file from the package has landed.  Please ping me if you update YUI's packaging as Francis suggested yesterday.  I'll need to change one line in contrib/maas_local_settings_sample.py if you change the place where the files are located.
<rvba> roaksoax: you'll see a new config option in contrib/maas_local_settings_sample.py: YUI_LOCATION.
<roaksoax> rvba: awesome! thanks. I'm emailing the java script team in Debian to talk about that
<rvba> roaksoax: cool.
<roaksoax> rvba: I cannot follow Francis suggestion libjs-yui35 because that'd mean introducing a new source and I'm not sure whether we wanna do that or not yet
<roaksoax> ^^
<roaksoax> smoser: ^^
<roaksoax> rvba: was the directory suggested 'yui/<version>/build/*.js'?
<rvba> roaksoax: it's not really suggested, but that's what the JS side requests by default.
<roaksoax> rvba: the JS side in *maas*? or generally?
<rvba> roaksoax: sorry for being vague, the JS side in YUi.  YUI3 has this mechanism where you load a small initial file and then this tiny bit of code requests the needed additional modules all in one request.
<rvba> roaksoax: does that make sense?
<roaksoax> rvba: kindof, is there any documentation that you could point me at?
<rvba> roaksoax: http://yuilibrary.com/yui/docs/yui/loader.html
<rvba> roaksoax: you'll see that the default 'root' option is '{version}/build'. Because the idea is to be able to have multiple versions of YUI3.
<roaksoax> rvba: right, but even so, we can only have 1 version of YUI 3.5.X
<roaksoax> ah nevermind :)
<roaksoax> rvba: does this make sense to you? http://pastebin.ubuntu.com/1040864/
<rvba> Looking.
<rvba> roaksoax: Look good.  One remark: I'd drop the part about having 'build' in the path.  I think this is the default because of the way the code is structured in the yui tarball (src/ docs/ build/ etc.).  But when it comes to having that packaged, it really makes sense to have only the files in build/ and drop everything else.  The main question is the about having the version in the path and the package name.
<roaksoax> rvba: right, ah I thgouht you wanted everything to be installed under ./build/
<rvba> No, YUI 'likes' it by default.  but I think it's just a convenience.  In a package I think it makes sense to drop that.
<roaksoax> rvba: ok
<roaksoax> rvba: ok cool. email sent!
<roaksoax> paultag: could you pelase repeat this for rvba to give his opinion
<roaksoax> rvba: ^^
<paultag> I was wondering how you suggested dealing with node.js policy, since it's a slightly different subset of javascript policy it's self - adding a version path will cause some pretty gnarly behavior (as much as I would kill to have scripted languages major-versioned)
<paultag> so I was wondering if you had an idea for how to keep javascript and node.js normalized, or if this was just to solve the problem at hand
<paultag> also, using update-alternatives for a "current" version of the lib would be nice to add, IMHO anyway
<paultag> (also wrt package naming, since node.js folk have some jacked up version schemes)
<roaksoax> so, TBH i'm not a JS expert, but was just given the task to upgrade the mpackages, and obviously by doing so, some concerns arised
<paultag> major version doens't always mean API stability :(
<paultag> roaksoax: of course, I totally ACK that there is a problem
<paultag> not that I do much javascript work, I was just here, saw @ubuntu and figured I'd see what you thought
<paultag> I'm just a casual member of that team
<paultag> javascript policy was written by dapal on the wiki, and it's very short -- getting it changed will not be so much of an issue, there are two active folks on that team ATM
<roaksoax> paultag: so I do not have an idea of keeping js and node.js normalized but would definitely make sense doing so, as well as using update-alternatives
<paultag> OK, I was just wondering :)
<paultag> node.js isn't in testing, so it's not so much an issue
<paultag> (whereas plain js libs are)
<roaksoax> right.
<roaksoax> let's see what rvba things :)
<roaksoax> rvba: ^^
<paultag> roaksoax: so, I'm guessing Jonas Smedegaard will be the first to reply
<paultag> anyway, just wanted to say hi and ask. Thanks, guys.
<roaksoax> looking forward to it
<roaksoax> paultag: thanks to you too though! as concerns like yours also made be hold on the upgrade and/or make changes that differ from Debian
 * rvba reads scrollback.
<paultag> roaksoax: reducing the delta is good for everyone :)
<roaksoax> indeed
<rvba> roaksoax: I confess I don't know anything about node.js but clearly it would make sense to treat YUI as a library and use the major version in the package.
<paultag> rvba: my main point is -- not all js libs treat the major-version as api stability (as well as the same policy covering both, for the most part)
<paultag> rvba: I agree that's a good way of doing it, though.
<paultag> (node.js would have to be treated as a  lib if it is (which is a good thing(tm)) - but node folks are really really (REALLY) bad about API stability)
<rvba> paultag: you're right so I guess it would be good to have two policies then.
<paultag> some of them don't even include license information, the situation is really gnarly.
<paultag> rvba: so that might be good to include in the proposal :)
<rvba> Right.
<paultag> (propose a branch) - as well as perhaps considering a update-alternatives pointer to the current version or something.
<paultag> again, I'm not a javascript authority. Just a lurking member who is also @ubuntu, and took the time to make sure I gave it some thought and a friendly hi
<rvba> And I'm definitely not a packaging authority. But I agree that the current policy seems to be veryâ¦ minimal, to say the least. Your idea sounds good to me.  What do you think roaksoax.
<rvba> ?
<paultag> (so, we're agreed, the current state sucks ;) )
<paultag> rvba: the "policy" was written by dapal to keep sanity -- if you check out his DDPO, you'll understand why it's so small
<paultag> 163 maintained packages :)
<paultag> a lot are node / js
<rvba> I see.
<roaksoax> well i guess he definitely has the last word on this then
<roaksoax> as he's the one who maintains all of those packages
<paultag> roaksoax: oh, no. The other one (Jonas) maintains 308
<roaksoax> but yes, I think a node.js policy would be a good idea
<paultag> also a few node packages (and nodejs it's self)
<roaksoax> oh wow
<roaksoax> those are quite a few packages
<paultag> alright, well, I've said my piece
<paultag> thanks, y'all.
<rvba> Thanks paultag!
<paultag> rvba: thank *you* for caring about this stuff :)
<paultag> (and wanting to upstream the delta)
 * paultag waves
<cheez0r> thank both of you ;)
<roaksoax> rvba: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-June/003709.html
<rvba> roaksoax: we're only interested in YUI packaging right now.  And 2.8.2 is largely incompatible with 3.5.
<kurt_> how do I map the cobbler system list names to the maas system list names?
<cheez0r> kurt_: in cobbler system dumpvars --name "NAME" there will be a dnsname field.
<cheez0r> you can correlate them using that field.
<cheez0r> dnsname == maas name.
<kurt_> thank you
<cheez0r> np
<cheez0r> it is kind of odd that nodename in cobbler is different than nodename in maas.
<cheez0r> but cobbler is being phased out of maas so it's a moot point.
<kurt_> I'm glad cobbler will be gone soon
<cheez0r> roaksoax: what is the pxe system that's replacing cobbler in maas?
<kurt_> ;)
<roaksoax> cheez0r: one developed in house
<cheez0r> cool.
<cheez0r> does it have a name, or will it just be maas-pxe?
<Daviey> no name, just a core part of maas
<cheez0r> cool
<roaksoax> indeed
<czajkowski> Daviey: ping
<czajkowski> bigjools: thank you
<bigjools> czajkowski: nae worries
<bigjools> czajkowski: those two I answered a FAQs BTW
<bigjools> are*
<czajkowski> bigjools: cool once I figure out how to create a FAQ on AU I'll do that tomorrow it was complaingin I didnt add a body to the text
<bigjools> heh
<bigjools> czajkowski: I added FAQs to LP as well
<czajkowski> ah yes but I've to add them to AU now
<kurt_> I'm playing around a bit with trying to provision via kvm controlled VM, and it appears the bridged connection is slow in reaching the maas server.  Only after the VM boots to hard disk does it get a dhcp address from the maas server.  Has this been observed?
<kurt_> its two bridged connectionsâ¦so maybe that matters?
<bigjools> I don't get that
<bigjools> have a look at the vdenv/ dir in the source tree, it sets a load of VMs up
<kurt_> maas server runs on VMWARE <--> kvm server with VM
<kurt_> both on same network, in my case 172.16.100.x
<kurt_> my kvm VM boots, looks for the dhcp server, doesn't find it, so boots to HD, then once it comes up on HD it finds the DHCP server and gets an IP address!
<kurt_> ie. tries to do a PXE boot is what I mean
<bigjools> I am not pxe booting on VMs
<kurt_> eh?
<kurt_> the vmware vms pxe boot
<bigjools> s/not// sorry
<kurt_> ?
<bigjools> I am pxe booting on VMs
<czajkowski> bigjools: for future reference do you want to be mailed or should I spread it around on the red team?
<kurt_> ok, back to trying to figure it out
<bigjools> czajkowski: send to the list
<bigjools> czajkowski: in a pleading tone :)
<czajkowski> list?
<bigjools> maas-devel
<czajkowski> maas devl?
<czajkowski> grand will do
<bigjools> ta
<czajkowski> not sure it'll be a pleading tone mind you
<czajkowski> ;)
<bigjools> domineering? :)
<czajkowski> forceful, or they wont get answered and it'll fall back to one person again :)
<czajkowski> anways I should in fact log off and attempt sleep
<bigjools> yes, you should indeed
<kurt_> yeah I get "connection timed out" from kvm VM each time - can you tell me what network driver you are using?  I was using virtio
<bigjools> ummm
<kurt_> sent you screenshot
<kurt_> or tried to anyways
<bigjools> just doing a virsh net-start here
<bigjools> seriously, look in the vdenv tree in the source
<kurt_> sorry.  I don't know what you mean.
<bigjools> http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/files/head:/vdenv/
#maas 2012-06-15
<kurt_> bigjools: not to sound silly, but I've not really worked with bz.  Is there a howto somewhere on how I would install this?
<bigjools> bz?
<kurt_> https://wiki.ubuntu.com/Bzr
<kurt_> reading about it now...
<bigjools> apt-get install bzr
<bigjools> bzr checkout --lightweight lp:maas
<bigjools> is all you need
<kurt_> thnx, will try that...
<bigjools> actually
<kurt_> ?
<bigjools> bzr checkout --lightweight lp:maas/1.0
<bigjools> you don't want trunk
<kurt_> eh, too late...
<bigjools> heh
<kurt_> can I stop in the middle?
<bigjools> well it might work, try it out
<kurt_> lol
<bigjools> just don't run the dev version, it'll conflict with installed packages
<bigjools> but the vdenv stuff should be ok
<kurt_> it appears to have installed - is there an easy way of removing/reversing that install?
<kurt_> ok, it didn't install, just create the folder branch
<bigjools> it's just creating a dir for you, remove it if you don't want it
<jtv> roaksoax, smoser: bigjools & I would like to know how the nodes obtain their ephemeral images.  Cobbler provides those over iscsi?
<kurt_> but what's the trick to getting the components in place after you have the directory?
<roaksoax> jtv: its all PXE
<jtv> roaksoax: but that's not a transport mechanism â how do the nodes obtain the images?
<roaksoax> jtv: yes iscsi. So cobbler ismply profives the kernel and initrd but the images are accessed via iscsi
<roaksoax> jtv: howeveer, a cobbler profile is the one who has the information about where it is located
<roaksoax> jtv: that's a kernel argument passed to the pxe file
<roaksoax> jtv: you guys also need to make sure it that users can pass custom kernel parameters
<jtv> One thing at a time thoughâ¦ we're in the process of replacing cobbler, so we need to know how we will provide the images to the nodes without cobbler.
<roaksoax> jtv: cobbler doesn't really provide the images. We simply tell the kernel on the PXE file where to obtain the image from
<bigjools> what is the option that tells it?
 * jtv strides out for urgent coffee
 * roaksoax expanding
<bigjools> is it set in the preseed that it gets from the url specified on the cmd line?
<roaksoax> give me a sec please
<bigjools> ok :)
<roaksoax> bigjools: http://pastebin.ubuntu.com/1041810/
<roaksoax> jtv: http://pastebin.ubuntu.com/1041810/
<roaksoax> jtv: i meant to write this as a response to your email
<kurt_> bigjools:  from our earlier conversation - what gets the bzr components in to place?
<bigjools> kurt_: what do you mean bzr components?
<bigjools> by*
<kurt_> I now have a "1.0" directory in my home directory
<kurt_> it has a lot of sub directories
<bigjools> inside there you'll see a vdenv/
<kurt_> how do I know where to install things?
<bigjools> look at it's README
<bigjools> its
<bigjools> don't necessarily run it blindly until you understand what it's doing
<kurt_> I did - as I recall it gave the basic install process for maas. i'll look again
<bigjools> kurt_: wrong readme
<bigjools> look in *vdenv*
<kurt_> kk
<bigjools> you're not installing maas, just using still in the source to set up VMs
<bigjools> s/still/stuff/
<bigjools> roaksoax: can you explain more about iscsi?
<roaksoax> bigjools: in short, maas-import-ephemerals sets up iscsi.
<bigjools> is it a local daemon?
<roaksoax> bigjools: yeah, it is tgtd running on the maas server
<bigjools> ah
<roaksoax> bigjools: so the only thing needed is that we are able to tell what kernel arguments to use in the PXE file
<roaksoax> bigjools: are you guys using the concept of "profiles" "systems" or anything similar?
<bigjools> no
<bigjools> not yet anyway :)
<roaksoax> bigjools: I could expand on how everything works for you guys to have a better view of what's happening with cobbler
<bigjools> we're trying to understand the process and see what works best
<bigjools> one of the nasty things about cobbler is that it needs to keep syncing its DB
<bigjools> now, I'm trying to remember how juju selects a different profile
<roaksoax> bigjools: it doesn't
<bigjools> preseed, I mean, sorry
<roaksoax> bigjools: it doesn't
<bigjools> :)
<roaksoax> bigjools: there's 1 preseed for enlistment. 1. for commissioning. 1. for deployments
<bigjools> so all the deployment preseeds have the juju stuff at the bottom?
<roaksoax> bigjools: no, there is one "snippet" that sources form a ks_meta variable (kickstart meta data variable). This snippet is maas_preseed and is sourced on the commissioning and the installation preseed
<bigjools> ah right that was it
<roaksoax> so the maas_preseed content is given by MAAS to cobbler in base64, and it's being decoded when the preseed is being obtained
<bigjools> it all comes back to me now
<roaksoax> bigjools: hheh
<bigjools> thanks roaksoax
<roaksoax> bigjools: anyways, I'll try to exapnd more on the whole process tomorrow.
<roaksoax> i'm off to bed
<roaksoax> have a good one
<bigjools> roaksoax: sleep well - we'll trudge on
<jtv1> bigjools: wip branch â https://code.launchpad.net/~jtv/maas/import-to-tftp/+merge/110451
<bigjools> jtv1: ok - late lunch here, back in a bit
<jtv1> ack
<jtv1> Hmm where should I put tests for my shell scripts?
<bigjools> jtv1: why bash and not python?
 * bigjools just got back
<jtv1> Turned out things stayed relatively simple after all.
<jtv1> I figured for this, shell had relatively little overhead to get to a working script.
<jtv1> Cyclomatic complexity is low.
<bigjools> fairy muff
<bigjools> jtv1: does cobbler cope with the race condition?
<bigjools> don't think it does does it?
<jtv1> Well it may just be restricted in its concurrency enoughâ¦  Really don't know.
<bigjools> jtv: well, ISTM that it can't know if something is booting when the files are replaced
<jtv> Maybe not â but that's not really needed anyway.
<bigjools> mebbe
<jtv> There's always tricks like adding a serial number to the directory name, so actual contents never change once created.
<jtv> (And then you can delete anything that's not the latest and also old enough that nobody should be booting from it any more)
<jtv> Basically MVCC much like postgres does.
<bigjools> future work I guess
<jtv> Indeed.  And we can do that in two phases:
<jtv> 1. Fix the actual problem by storing each image in a separate directory.
<jtv> 2. Offline GC wants disks actually start filling up.  :)
<jtv> s/wants/once/
<bigjools> jtv: so I think the script looks ok enough but as you say it'd be nice to know it works
<jtv> bigjools: it's really deafeningly simple, because it does not deal with ephemeral images, nor with preseeds.
<bigjools> famous last words
<jtv> It downloads the pxelinux.0 for each architecture's latest release, and the linux & initrd.gz for each release, for each architecture.
<jtv> And insofar as there are any changes, those are moved into the TFTP tree according to the filesystem layout I documented.
<jtv> AFAICT the only reason why preseeds are mentioned at all in the existing script is that they need to be defined with the Cobbler profile.  We can bypass that completely because that information comes from the database.  Nothing to do with providing images.
<jtv> Oh FIDDLESTICKS
<jtv> Seriously, wget, SERIOUSLY?
<jtv> You do all this stuff and then âfile://â URLs are too hard for you?
<bigjools> heh
<jtv> NOT FUNNY
<jtv> This undermines my test pretty thoroughly.
<jtv> And why?  Why?
<jtv> Don't answer that.  I know: because nobody ever tests this kind of code.
<jtv> Grrr.  I need to rethink this.
<bigjools> heh
<bigjools> right.  Morning rvba!  And, good night everyone.
<rvba> \o bigjools.
<rvba> Hi jtv.
<rvba> jtv: time for a tiny review? https://code.launchpad.net/~rvb/maas/bug-1013275/+merge/110475
<ubot5`> Ubuntu bug 110475 in mozilla-thunderbird (Ubuntu) "âTB crashâ" [High,Invalid]
<jtv> Good morning rvba
<jtv> Sure, I'll take it
<jtv> rvba: done
<rvba> ta
<jtv> rvba: maybe you can give me some feedback on this idea.  In order to test my download script (replacement for maas-import-isos, basically) I want to pass wget a file:// url.  The test shouldn't download from the real Ubuntu servers, obviously.
<jtv> But guess what: wget does not support file://!
<jtv> I'm thinking, I could make it work if I insert a fake wget in the path that just links to curl.
<jtv> Oh blast, no, I'm passing other options to wget.  :-(
<jtv> Hmm...  Maybe I can work around that.
<rvba> Or you can use the http fixture to create a temporary http server.
<rvba> jtv: from maastesting.httpd import HTTPServerFixture
<jtv> Seems a bit heavyweightâ¦
<jtv> There.  I've got an easy way to make it use curl instead.
<jtv> By the way, I guess we should document our dependency on distro-info.
<rvba> How will you manage to deal with the arguments you pass to wget?
<rvba> When we will introduce the dependency, we definitely will.
<jtv> We've been using distro-info for some time now.
<rvba> Oh, right in scripts/maas-import-isos.
<jtv> Yup.
<jtv> I just added it to the hacking doc.
<rvba> Cool.  I filled a bug about using it to list the supported distros inside MAAS, I thought you were talking about that.
<jtv> No, just the script.
<jtv> My own script uses it as well.
<jtv> In particular, my script uses it to get the current Ubuntu release.
<jtv> (In addition to the list of releases, of course).
<rvba> By the way, this script also sets up the profiles in cobbler.  I suppose you're simply dropping that right?
<jtv> Yes.
<jtv> Well, actually dropping it will be a separate step, of course.
<jtv> But I'm not re-creating it.
<rvba> Sure, good.
<jtv> The profile creation does one other thing that I don't do: store preseeds.  We do that from the database.
<jtv> Not a job for a download script.
<rvba> Right, Gavin and I are working on that.
<rvba> We're not sure we will need to add the notion of 'profile' right now.  So we will create something simple to get started and then we will iterate on that.
<jtv> Makes sense.  My guess is we'll need _something_ that's similar to a profile, but it's hard to say now where all the parts will come together.
<rvba> Exactly.
<rvba> We will start by generating preseed files "on the fly" given the proper arguments (node, release, type of preseed {commissioning, etc}).
<jtv> On node status change, I guess?
<jtv> (BTW bear in mind that we may not know which of its MAC addresses a node will use during pxe boot)
<rvba> No, really "on the fly", so it will be generated when we will need it.
<jtv> Doesn't that usually coincide with node status changes?
<rvba> Well, we will add a way to actually see the preseed file in the UI.  This is not linked to the status being changed.
<rvba> But obviously, we will expose that on the metadata API too.
<jtv> You're probably aware, but just in case: you can now access the metadata for any given node, in dev/demo mode.
<rvba> Yep, I've seen this.
<Daviey> czajkowski: hola
<czajkowski> Daviey: care to reply to maas mail with some suggested faq
<czajkowski> :)
<Daviey> czajkowski: nah
<Daviey> but thanks for the offer.
<jtv> You know?  This is what I'm here for.
<jtv> The love.
<czajkowski> jtv: he's a charmer !
<jtv> czajkowski: whatever you do, don't fall for his smooth manners.
<Daviey> :D
<Daviey> czajkowski: i will. i'm pulling your chain.
<jtv> You âyankâ someone's chain, or âpullâ their legs.  Pick one.
<jtv> Because otherwise, it sounds suspiciously like you're trying to flush czajkowski down the toilet.
<Daviey> jtv: aww, the key is to not specifically identify the meaning.
 * jtv mumbles something about coding style
<Daviey> lol
<Daviey> jtv: Which successes did you have overnight?
<jtv> That's a rather personal question.
<czajkowski> jtv: hah
<Daviey> jtv: Over MY night, your morning :)
<jtv> But hey, I don't have Daviey's smooth manners do I?
<Daviey> <-- smooth to the core.
<jtv> Oh, THAT night.
<jtv> Well, I have a working download script for the regular (install) initrd/kernels.
<Daviey> \o/
<jtv> I'm working up tests to run it through its paces; just got the first one passing.
<jtv> So I seem to be on the right track as far as that is concerned.
<Daviey> jtv: and it injects them where?
<jtv> Injects what where?
<Daviey> jtv: it downloads them.. but stores them where?
<jtv> In /var/lib/tftpboot/ according to the documented directory structure.
<jtv> Not the test, of course; that downloads from a local temporary directory and stores to a local temporary directory.
<jtv> Daviey: https://code.launchpad.net/~jtv/maas/import-to-tftp/+merge/110451
<jtv> Hope you'll find it easy to follow, as shell script goes.
<Daviey> jtv: I thought it was going to be stored in something like /var/lib/maas/XXX/, and generate /var/lib/tftpboot/ structure as a separate step?
<jtv> Arguably â but the intermediate step is in a temp directory.
<Daviey> jtv: ok, looks neat :)
<jtv> If downloading a kernel fails it won't leave you with an updated initrd.gz that doesn't match your remaining old kernel, if that's what you mean.
<Daviey> jtv: side note, we need to make sure that we can support importing, without having internet access aswell.
<jtv> The archive URL is configurable.
<jtv> Also, download failures on pxelinux.0 are ignored.
<Daviey> jtv: it's more a case of, i can see /var/lib/tftpboot getting inconsistent, so being able to regenerate based on what maas already knows is useful IMO
<Daviey> but yes, this is a good first step in that direction
<jtv> Well this is only for downloads.  Generating files is a whole other step.
<Daviey> right
<Daviey> sounds good :)
<Daviey> i'll stop distracting you now.
<Daviey> :)
<jtv> :)
<jtv> Got a call coming up anyway
<Daviey> jtv: My intent is Tues and Thurs, others by need.  You can see too much of eachother, right.
<jtv> Quite
<jtv> By the way, Daviey, has anyone tried the new random-node metadata access yet to your knowledge?
<Daviey> jtv: random node?
<Daviey> Sorry, can you remind me what this is?
<jtv> Daviey: where you get access to any node's metadata.
<jtv> Perhaps I should say arbitrary.
<jtv> But we accept the word in Random Access Memoryâ¦
<Daviey> ahh
<Daviey> i see.. i explored it myself.. but not used it in anger as yet
<jtv> Well if the exploration turned up no problems, then I'll call that a success at least as far as it goes.
<Daviey> jtv: \o/
<Daviey> Always good to end the week with noted success.
<jtv> Well I'm quite happy already that I've finally got a new download script up for review!
 * jtv stretches legs
<Daviey> \o/
<rvba> Daviey: sure.
<Daviey> rvba / allenap: Do you have a list of deps you still need from pypi?
<Daviey> the correct fix should really be to package them up IMO
<Daviey> Alternatively, our brothers in openstack-ci have a local pypi mirror for the deps they need.  That is another alternative.
<rvba> Daviey: allenap will confirm that but for some reason, python bootstrap.py insists on downloading stuff.  stuff=zc.buildout.  Installing the package does not solve the problem.
<Daviey> i *love* buildout.. it does so much for us. :)
<rvba> Daviey: is it easy to spoof pypi.python.org to localhost?
<allenap> rvba: We can point buildout/distribute wherever we want.
<allenap> rvba, Daviey: I thought of just putting the packages in my public_html on people.c.c.
<allenap> As an experiment.
<rvba> allenap: the problem is the 'python bootstrap.py' run right?
<allenap> rvba: The problem is everything :)
<allenap> rvba: I /think/ we can address that, but we also need the deps for after that.
<rvba> allenap: putting the deps in ~/.buildout should be enough for "after that".
<allenap> rvba: Okay. We need to store those deps somewhere. What we use for Jenkins we should also use for ourselves, don't you think?
<rvba> allenap: well, since all of us have internet access the current situation works fine for us.  If we need to hack something real quick to get Jenkins to work then it's fine by me.
<allenap> rvba: Okay, deal. We figure out the zc.buildout thing, then hack the cache for Jenkins.
<allenap> As in zc.buildout gets a proper fix, Jenkins gets duct tape?
<rvba> allenap: WFM :)
<rvba> allenap: I like Daviey's idea of spoofing pypi.python.org.  But I'm not sure what it means exactly.
<allenap> rvba: Using lp:~allenap/maas/effing-download-cache, http_proxy=http://localhost:1234 make build --> http://pastebin.ubuntu.com/1042191/ (i.e. it tries to download zc.buildout, fails, but then builds *fine*, pos)
<rvba> allenap: well, if matsubara-lunch can try that on the Jenkins box and it works, then \o/.
<allenap> rvba: It's caused by the index.obtain(...) line in bootstrap.py.
<matsubara> allenap, rvba: doesn't seem to work
<matsubara> allenap, rvba https://pastebin.canonical.com/68213/
<Daviey> rvba: I mean having a fake pypi mirror, that is bascially all
<Daviey> rvba: see, this is what openstack does http://pypi.openstack.org/
<Daviey> mirror of the tar packages they care for.
<allenap> matsubara: lp:~allenap/maas/effing-download-cache now has a fix for the always-downloading-zc.buildout problem. Can you try populating ~/.buildout/cache/dist (I can get you content here if you don't have any somewhere), then try building this branch?
<matsubara> allenap, https://pastebin.canonical.com/68214/ that's the content of the cache/dist dir
<matsubara> allenap, still got the MissingDistribution
<matsubara> ah the problem is that the cache in the jenkins machine is missing psycopg
<allenap> matsubara: I'm going out now, but I'll be back later. I've added virtualenv support to effing-download-cache, which allows us to install buildout without using its ungood bootstrap.py script.
<rvba> matsubara: allenap is the real specialist here but I'm back from lunch and ready to help you if I can.
<matsubara> rvba, cool. I was uploading the files to the cache and now am re-running make build
<matsubara> rvba, looks like make build worked this time when I updated the cache (without updating the branch with the latest changes from allenap)
<rvba> matsubara: \o/.
<allenap> matsubara: \o/
<allenap> matsubara: Which changes, if any, did you get from my branch? I'll get them reviewed and landed.
<matsubara> allenap, rvba: oh, sorry!!! I ran the make build in the wrong terminal and of course, locally, it just work! (/me is embarrassed)
 * matsubara fetches brown paper bag
<allenap> Haha :)
<rvba> :)
<matsubara> allenap, rvba: make build is now complaining it can't find lxml: MissingDistribution: Couldn't find a distribution for 'lxml==2.3.2'.
<allenap> matsubara: Ah, that has to be installed on the system.
<matsubara> but that's installed as a package. shouldn't it fallback to the system one rather than trying to download one or use from the cache?
<matsubara> unless...
<matsubara> ii  python-lxml    2.3-0.1build1  pythonic binding for the libxml2 and libxslt
<matsubara> grrrr
<matsubara> the system one is old!
<matsubara> No LSB modules are available.
<matsubara> Distributor ID: Ubuntu
<matsubara> Description:    Ubuntu 11.10
<matsubara> Release:        11.10
<matsubara> Codename:       oneiric
<matsubara> argh, jenkins machine is running oneiric
<rvba> !
<allenap> Oh dear god.
<matsubara> I think we have a bigger issue now
<allenap> Haha :)
<rvba> Indeed :(
<matsubara> ok, I'll have to talk to Larry about this. there are too many things running on that machine for me to just dist-upgrade. I'll let you know through the list. sorry about the confusion
<allenap> matsubara: Good luck! :)
<matsubara> thanks :-)
<allenap> matsubara: A schroot would work.
<matsubara> hmmm that's a good idea. Any good docs to set that up? Maybe I can setup a schroot and a exclusive node to run MAAS on without the need to update the whole OS of the Jenkins master
<matsubara> ok, I'll sort it out with Larry as I'll definitely will need help. If I can't get done this today, I'll email the list an update
<matsubara> and if you have a good doc about the schroot let me know
<allenap> matsubara: https://dev.launchpad.net/Running/Schroot is a doc I followed one. The man page is really good too.
<allenap> s/one/once/
<matsubara> cool. thanks!
<jtv> I'm off.  nn everyone!
<allenap> rvba: Got time for a review? https://code.launchpad.net/~allenap/maas/effing-download-cache/+merge/110534
<rvba> allenap: sure.
<allenap> Thanks!
<rvba> roaksoax: Hi Andres, I've got a question for you.  I'm working on the preseed snippets/template and I notice that the variables are indicated by a '$' sign (e.g. $http_port).  That's all right but now, in a snippet (maas_proxy to be precise), I've found a different syntax: "d-i     mirror/http/proxy string http://@@server@@:8000/".  Would you know why we have a different syntax here?
<rvba> roaksoax: I suspect this means that this is interpolated at a later stage (i.e. not during the preseed generation).  Am I right?
<roaksoax> rvba: yeah, it seemed to me as they first used @@server@@ but then changed to use $
<rvba> roaksoax: Ah ok.
<rvba> Thanks.
<roaksoax> rvba: although, it also seems that @@server@@ is a global variable, while '$' is a local variable, per system, profile, distro etc
<rvba> roaksoax: oh, I think it's only a funky cobbler extension to Cheetah templates.  I just spotted http://paste.ubuntu.com/1042515/ in cobbler/templar.py.
<roaksoax> I see
<roaksoax> yeah it is a funky thing indeed
#maas 2013-06-10
<roo9> anyone know if you can make maas cli give out IPMI details?
<roo9> and/or maas api
<roaksoax> roo9: you can configfure ipmi settings through the cli yes
<roaksoax> if that's what you mean
<kumquat> hi all.  would anyone happen to be able to pinpoint where a maas node talks to the server to send back its lshw information?  I'm trying to store other network details and would like all of it to be done in the same communication period.
<kumquat> Right now i'm looking at nodecommissionresult and the metadataserver api classes but I can't seem to trace back the store_details function calls to where they're actually used.
<smoser> kumquat, it depends on the maas version
<smoser> but the stuff runs in commissioning stage
<smoser> and in latest (raring) you can add user-data commissioning scripts (i think in the UI) that will run
<smoser> and their output is put in
#maas 2013-06-11
<bigjools> mwhudson: did you get anywhere with the split downloads yet?
<mwhudson> bigjools: no
<bigjools> mwhudson: fair enough :)
<mwhudson> bigjools: i seem to have about three jobs all of a sudden!
<bigjools> \o/
<mwhudson> bigjools: did you get anywhere with your ... stuff?
<bigjools> mwhudson: if you're talking about the sekrit stuff, waiting on a third party
<mwhudson> ok
<mwhudson> (i was)
<roaksoax> rvba: still around?
<rvba> roaksoax: yes, but otp
<roaksoax> rvba: ok let me know when done :)
<rvba> roaksoax: what's up?
<roaksoax> rvba: so I was wondering when are we going to have the autod-distro detection/;selection mechanisms
<roaksoax> or whatever is it that you guys are planning to have there?
<rvba> roaksoax: you mean using distro-info's output instead of hardcoding the name of the releases?
<roaksoax> yeah
<roaksoax> rvba: I guess a better question would be what are the plans around it exactly? I think it would make sense to either do 1 of two things 1. maas-import-pxe-files determines which releases are available in MAAS itself, by enabling those for which we have images of. or 2. select the images that we will import in MAAS and make them available for maas-import-pxe-files to import
<rvba> roaksoax: it's definitely in a blueprintâ¦ but I confess we haven't thought about it muchâ¦
<roaksoax> rvba: i think it is something that we really need to care about soonish
<roaksoax> and try to SRU it
<ehw> hey, guys, anyone know how to set the "public ssh key" in juju-core? -ENODOCS
<ehw> getting this: error: error parsing environment "maas": no public ssh keys found
<AskUbuntu> Node is still in commissioning state! | http://askubuntu.com/q/306911
#maas 2013-06-12
<_nbk_> hello,
<_nbk_> i need help to enlist the 1st node. It does not show up in the List on the controller in the Browser.
<_nbk_> On the node screen an error message is running: "bmc-config:xxxx map pfn expected mapping type uncached-minus xxxx-xxx, got write-back"
<rbasak> Sounds like that could be a problem related to IPMI on that hardware. What hardware is it?
<_nbk_> both boxes core i5, asus board P8H67-I
<_nbk_> the node is booting fine from the maas-controller but after all these bmc- messages it also has a curl error about the ssl certificate
<rbasak> What's the error exactly?
<_nbk_> i could not read the error about curl and the ssl certificate so fast. i will reboot the node and try again. I have a bad netskin in my eyes :-(
<_nbk_> syslog shows all errors about bmc-config but not the error about the ssl certificate
<rbasak> Use a camera, perhaps?
<rbasak> It might be worth installing one node manually and checking that freeipmi works correctly with the BMC on it.
<_nbk_> i use my phone to take a picture.
<_nbk_> curl: (60) SSL_Certificate problem, verify that the CA cert is OK. Details:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
<_nbk_> More details here: http://curl.haxx.se/docs/sslcerts.html
<_nbk_> i would like to use the -k (or --insecure) option on that screen because i have the self signed certificate.
<_nbk_> so what can i do to get the 1st node enlisted?
<roaksoax> jtv: ping
<jtv> Hi roaksoax
<roaksoax> jtv: howdy!! so I was wondering something
<roaksoax> jtv: how to compare that {} is {} in a test?
<roaksoax> jtv: MismatchError: None is not {}
<jtv> Then clearly it's not {}.  :)
<jtv> You can test that x is an empty dict by doing self.assertEqual(x, {})
<roaksoax> jtv: yeah, so I was comparing None with {}. but I want to compare that {} is {}
<jtv> I think I may be missing something here...  one of the two must be a variable, and the other a constant, right?
<jtv> Because we already know that {} equals {}, although {} is not {} in the sense of the "is" operator.
<roaksoax> jtv: http://paste.ubuntu.com/5758477/
<jtv> That should work, if get_snippet_dir() really returns {}.
<jtv> Ahem â get_snippet_context
<jtv> nog get_snippet_dir
<roaksoax> jtv: yeah, that worked! thanks! (and yeah was adding that test as per your recommendation)
<jtv> Ah :)
<jtv> Some background: there's "{} == {}" (which is true),
<jtv> and there's "{} is {}" (which is false).
<jtv> The reason the latter is false is that "is" compares the identity of the objects.
<roaksoax> jtv: test_get_snippet_context_empty_if_no_snippets ->> the test renamed like this sounds better?
<jtv> Yes, that's good.
<roaksoax> jtv: right, I see, similar to the 'is None' to 'if not None' case
<jtv> Yeah â there's only one None.
<roaksoax> jtv: btw... are the tests broken in saucy?
<jtv> That's why you can compare with "is None."  The "is" operator basically compares the pointers you pass it, instead of the things they point to.
<jtv> Tests should work in Saucy, I think.  But there are sometimes changes that break them.
<jtv> What are you seeing?
<roaksoax> jtv: stuff like: http://pastebin.ubuntu.com/5758493/
<roaksoax> jtv: so I upgraded to saucy and tests are now broken, initially thought it was because i did something (like have maas installed), but I removed it and dunno whether it is related
<jtv> Oh dear
<jtv> This looks a bit as if piston's put() no longer returns anything.
<jtv> Let me just see if I can try that on a Saucy system.
<roaksoax> jtv: yeah, better double check cause I did a raring->suacy upgrade which might have left something unclean, hence causing this
<jtv> Right.  It shouldn't, but then again, there shouldn't be any failures.
<jtv> roaksoax: seeing errors too...  :(
<roaksoax> boomer
<jtv> Boomer?  Isn't that the robot dog from the original Battlestar Galactica series?
<roaksoax> lol no idea :)
<ehw> erâ¦ no that was moffet
<ehw> boomer was the (only?) African-American pilot
<jtv> Ah thanks
<ehw> just doing my job *tips hat*
<jtv> roaksoax: at least some of the errors seem to be related to a change in django 1.5.  The tests seem to hang, so I'm not seeing the other ones yet.
<roaksoax> jtv: so I'm looking at this: https://jenkins.qa.ubuntu.com/job/maas-merger-trunk/319/console
<jtv> Hmmm
<roaksoax> jtv: it seems that the tests are testing the rendering of the preseeds (including the enlistment preseed, but instead of calling render_enlistment_preseed for the case of enlistment, it is calling render_preseed
<jtv> Yes, IIRC render_preseed has to decide which one it should render.
<roaksoax> jtv: right, that's only for commissioning or install
<roaksoax> jtv: but enlistment has its own render_enlistment_preseed
<roaksoax> jtv: since there's *no* node status for enlistment, then obviously the test would be testing the wrong stuff :)
<roaksoax> jtv: so we are basically saying "node.status is commissioning, but test the enlistment preseed" ((i think)
<jtv> I don't remember what it was that drove the decision "oh, this node is enlisting" but we'd probably have a comment to mark the spot.
<roaksoax> jtv: oh no, i know wthat the issue is.
<jtv> ?
<roaksoax> jtv: so the running code calls render_enlistment_preseed for enlistment, and for everything else, render_preseed is called
<roaksoax> jtv: however, the tests are testing for the enlistment preseed using render_preseed
<jtv> Ah.  Maybe the test could assume at some point that the status didn't matter, and that changed?
<roaksoax> jtv: so the status always matters, if a node enlist then it has no node status
<roaksoax> jtv: so the test is testing depending on PRESEED_TYPE,
<roaksoax> jtv: http://pastebin.ubuntu.com/5758742/ --> you'll find the explanation there
<jtv> Damn non-wrapping pastebin...
<roaksoax> yeah!
<roaksoax> jtv: so see what I mean? so test_render_preseed should only test for escenarios with COMMISSIONING, DEFAULT preseeds, while test_enlistment_preseed should test for ENLIST and ENLIST_USERDATA
<jtv> I have no idea why load_preseed_template consists of exactly (1) an enclosed function definition and (2) a call to that function.  I feel like punching someone.
<roaksoax> jtv: I'm guessing that the key here is that the preseeds (default, commissioning) are being loaded depending on the node.status, while the enlistment preseeds are not
<roaksoax> and that's where the difference lies in the code
<jtv> Yes, I recall it being something like that.
<roaksoax> however, in the tests they do test as if both type of preseeds where the same
<jtv> Maybe it was a matter of the node itself being None...
<jtv> Ah
<roaksoax> jtv: so this is what it should kinda do http://paste.ubuntu.com/5758765/ (note that it is just an example)
<jtv> Any idea why this worked before and breaks now?
<roaksoax> jtv: yes, it is broken now becuase the maas_ipmi_autodetect stuff for enlistment is inserted in the context in render_enlistment_preseed, but since test_render_preseed calls render_preseed() for the enlist/enlist_userdata templates, then they cannot find the variable in the context
<roaksoax> jtv: so doing this would fix it: http://paste.ubuntu.com/5758777/
<roaksoax> (or should)
<roaksoax> I'm gonna test that
<jtv> Doesn't look quite right to circumvent the test scenarios like that though...
<roaksoax> jtv: this is what it does the test itself though: preseed = render_preseed(node, self.preseed, "precise")
<roaksoax> where self.preseed would be *all* preseeds
<jtv> Yes, IIRC the code was deliberately kept very indifferent to that.
<jtv> Maybe the test can be split up into two scenarios?
<jtv> One for enlistment preseeds, one for the rest?
<jtv> Although it is nice to know that all scenarios are tested, even in stupid combinations...
<roaksoax> jtv: in reality it is already split in 2 different scenarios
<roaksoax> the problem was that the render_preseed scenario was also testing for enlistment preseeds
<jtv> So then maybe that could just return if this-is-an-enlistment-preseed-type?
<roaksoax> jtv: so how can I filter here: http://pastebin.ubuntu.com/5758815/
<roaksoax> jtv: something like. startswidth('ENLIST')
<roaksoax> to filter the nelistment preseeds out of it
<jtv> Is the filtering appropriate for the entire test case?  Or just for some of the test functions inside it?
<jtv> If it's just a few test functions inside it, you can put an "if" inside the test.  For instance, you could just "return" early on if the preseed type starts with ENLIST.
<roaksoax> jtv: there's just 2 functions for the class that test this, and both functions uses it
<roaksoax> jtv: so I would say that it is necessary to filter it
<jtv> If it's the entire test case, then list comprehensions also support "if":
<jtv> scenarios = [
<jtv>         (name, {'preseed': value})
<jtv>         for name, value in map_enum(PRESEED_TYPE).items()
<jtv>             if not value.startswith('ENLIST')]
<roaksoax> jtv: ok awesome! thakns
<jtv> Good luck...  I'll see what I can find out about the Saucy failures.
<roaksoax> jtv: ok this does it: http://paste.ubuntu.com/5758825/
<jtv> roaksoax: don't forget to update those comments!  It's no longer "each possible value" of preseed type.
<roaksoax> jtv: http://paste.ubuntu.com/5758831/ -> alright, this way the test_render_preseed tests everything but enlistment preseeds, and test_render_enlistment_preseed() will test all enlistment preseeds other than just one
<jtv> roaksoax: careful!  The comments should say "why" â the "what" is often clear from the code already.
<jtv> You could say something like "test against all preseed types, except the enlistment ones.  Those have their own test case."
<jtv> (It may seem silly to say what's coming later in the file, but somebody who's reading it has to start somewhere and then all the other stuff is still a mystery to them)
<ehw> does anyone have any go-juju maas docs I can follow? I'm havingâ¦ issues getting this running
<roaksoax> jtv: ok, updated
<roaksoax> jtv: https://code.launchpad.net/~andreserl/maas/consolidate_maas_ipmi_autodetect/+merge/167806
<jtv> Looking...
<jtv> (diff still updating)
<roaksoax> jtv: done now
 * jtv reloads
<jtv> roaksoax: looks like it's even going to extend enlistment-preseed test coverage a bit...  Do tests pass now?
<roaksoax> jtv: yeah they do
<jtv> \o/
<roaksoax> \o/
<jtv> Then land it!
 * jtv is off
#maas 2013-06-14
<bigjools> roaksoax: did you see the last comment in https://bugs.launchpad.net/bugs/1051626
<bigjools> how could pserv possibly be starting only bound to localhost?
<ubot5> Launchpad bug 1051626 in MAAS "PXE boot not working in virtual environment" [High,Incomplete]
 * roaksoax looks
<roaksoax> bigjools: that seems just plain stupid :)
<roaksoax> bigjools: i mean, we specifically tell it tolisten on all interfaces right?
<bigjools> roaksoax: I thought so
<roaksoax> bigjools: if maas and nodes are separated by a physucal network, it could be 2 things 1. STP/PortFast being enabled in the switch. 2. VBox messing things up
<roaksoax> and I think it might be VBox
<roaksoax> wouldn't be the first time
<bigjools> indeed
<roo9> i used vbox to debug/test my initial maas deployment, worked good
<roo9> bridged to eth0
<roaksoax> roo9: good to know! I've seen a couple situations on which mpeople has had trouble making it work
#maas 2014-06-09
<jtv> allenap: can't say I like the split-range solution, but I do appreciate the potential rabbit hole...  So the default is just a split-down-the-middle kind of line?
<allenap> jtv: I think bigjools was falling on the side of making the static range bigger than the dynamic range. 1:3 maybe?
<jtv> Thinking out loud...  I guess the need for the dynamic range depends on two factors: hosts that you want in the dynamic range, and lease times for transient leases.
<jtv> If we had separate networks, I guess it might make sense to restrict routing of BMC addresses, and just leave the BMCs in the dynamic network.  But I guess that's not applicable to the split range.
<jtv> So the dynamic range would be unallocated machines and additional unmanaged local services.
<jtv> You'd mostly want local services exposed on reliable IPs though, so probably not much of that.
<jtv> Hmm... maybe in the future if we found that a bunch of machines only work for other machines on the same network.
<jtv> Allocating static IPs won't be any great pain though unless it becomes a part of security policy, and we couldn't recommend that with a split range.
<allenap> jtv: To complicate matters, apparently BMCs are often put on separate networks anyway, and given static addresses by hand.
<allenap> Maybe that simplifies things :)
<jtv> They should be, yes â unless admins decide that it's a fully controlled network.
<jtv> I wonder if that includes "tabletop clusters."  I wouldn't mind forcing an opinion about this, but I would mind raising the threshold to getting set up.
<jtv> It'd be annoying to set up a MAAS with a /24 network and 100 machines plus BMCs, and find that we can't DHCP them all.
<jtv> OTOH, "don't do that then."
<allenap> jtv: I think itâs only a policy decision by larger customers. Tabletop clusters are probably all single network
<allenap> jtv: Indeed it would :-/
<jtv> The initial setup period may be an example of a situation we think of as uncommon: loads of unallocated machines.
<jtv> So I would say that the static and dynamic range must both be large enough to accommodate all your machines anyway.  Fifty-fifty may simply be the easiest way to "sell" that notion.
<jtv> Maybe we should describe the problem as âminimising the cost to your network's address range.â
<jtv> If we do a 3:1 split one way or the other, then the worst case is requiring 4 times as much IP space as the machines would normally require.
<jtv> That's OK if we can _reliably_ model the needs; the best case is requiring â more IP range than the bare machines need, which is nice.
<jtv> It's also OK if we can _reasonably_ ask people to work around a shortage if it appears.
<jtv> (We can perhaps ask people to move dynamically-addressed machines to static addresses, but not the other way around.)
<jtv> OTOH if we run out of dynamic addresses we can "borrow" from the static range.
<allenap> jtv: Given the use of containers and, when theyâre on the same network, BMCs, we may want to have the dynamic range be a multiple of the static range.
<allenap> rather than the other way around.
<jtv> Yeah.  It doesn't suit the steady state very well though.
<jtv> We could also treat the dynamic range as nothing more than a loading dock for the static range.
<jtv> Where everything that shows up in the dynamic range gets lifted into the static range.
<jtv> (Assuming we can find a way to convince systems that their old DHCP lease is worthless and they need to request a new one.)
<jtv> Sorry for re-doing much of the Austin discussion; there wasn't quite enough time to go through the whole problem and solution there IIRC.
<allenap> jtv: That would be okay. It implies that we need a way to allocate static addresses to containers and BMCs.
<jtv> Yes, we'd effectively be managing our own DHCP but piggybacking on dhcpd for the protocol niceties.
<allenap> jtv: I think the reason we keep circling back to this conversation is that the split-range solution is not much of a solution. Itâs giving us a new set of headaches.
<jtv> Yes...  Horrible unforeseen complications aside I quite liked the idea of link-local addresses myself.
<jtv> I'll say this for the fifty-percent solution: it puts a simple and reasonable upper bound on the cost to your address range.
<jtv> |range| â¥ 2Ã|nics| + 2
<jtv> (Where the +2 comes from broadcast & base addresses)
<allenap> jtv: Sounds good to me. Without a clairvoyant AI in MAAS I doubt weâll do any better :)
<jtv> You don't need a clairvoyant AI.  You need a paranoid one.
<jtv> Clairvoyance is great for average cases, but paranoid limits worst cases.
<allenap> Hehe. Or Go. Go solves everything.
<jtv> Who's up for a pre-imp about DNS changes for the new DHCP range?
<allenap> jtv: I am. Sorry I didnât see this until now.
<allenap> jhobbs: Thanks for testing the lease parsing thing.
<rkdemon2> Hi,
<jhobbs> allenap: np
<allenap> jhobbs: One thing: you need to change the verification-needed tag to verification-done.
<rkdemon2> I am new to this entire domain of openstack/maas etc. I am trying to deply juju on my platform. As a precurosr I needed to have a maas cluster up: I created a maas cluster with one node (can add more), but one for now. The "nodes" on the maas server page shows this:       ubuntu1         52:54:00:b7:fb:7e      Commissioning   default
<rkdemon2> I am looking for a way to test this before attempting to deply juju.
<rkdemon2> Any help would be seriously awesome!!
<jhobbs> allenap: done
<rkdemon2> anyone ?
<jhobbs> rkdemon2: https://maas.ubuntu.com/docs/juju-quick-start.html
<rkdemon2> jhobbs: I intend to use that link but wanted to know if there's an easy way to tell if the cluster is indeed setup.
<rkdemon2> jhobbs: When I "add a node" to the maas server, does the fact that the node get added enough to indicate it is setup  ?
<jhobbs> rkdemon2: you can commission/install it then ssh into it
<rkdemon2> to clarify, I added the node as a virsh node.
<rkdemon2> i.e specified the mac id of the virsh virtual machine created on another server as a node
<jhobbs> did you setup power controls for it?
<rkdemon2> no I do not know how to .. do I need it ?
<jhobbs> yeah - http://maas.ubuntu.com/docs/nodes.html
<rkdemon2> the vm is up  and created etc
<jhobbs> there is a section on that doc talking about power controls for vm nodes
<rkdemon2> ok thanks.. let me read .. thank yo ufor your help
<jhobbs> np
<d_`> is there any sort of managed login strategy for maas?
<d_`> each admin has their own key, but we share cluster resources
<d_`> it _seems_ like it's trying to associate provisioned servers to a single user
<dpb1> Hi -- when you create a container (lxc) on maas through juju, you get a non-critical error: 'sudo: unable to resolve host juju-machine-0-lxc-2' when running sudo commands -- should this be a bug in juju?  Maas?
<lazyPower> dpb1: thats kind of expected behavior since that hostname is unresolveable. Whats your resulting hostname in /etc/hosts of the lxc container?
#maas 2014-06-10
<dpb1> lazyPower: It's a general juju problem, afaict.  I filed a bug: https://bugs.launchpad.net/juju-core/+bug/1328269
<ubot5> Ubuntu bug 1328269 in juju-core "lxc: sudo: unable to resolve host" [Undecided,New]
<bigjools> any takers? https://code.launchpad.net/~julian-edwards/maas/static-range-in-ui-api/+merge/222590
<rvba> bigjools: on it
<bigjools> ta
<bigjools> rvba: solved my chained task queueing
<bigjools> it's rather easy
<rvba> bigjools: \o/
<bigjools> rvba: create a subtask/signature with mytask.s(args, kwargs)
<bigjools> then call .set(queue=foo) on it
<bigjools> :)
<bigjools> then you can throw them in a chained task, which itself doesn't require any queue applied, you just call its apply_async()
<rvba> bigjools: don't you have a special keyword argument to pass that directly when creating the task?
<bigjools> no
<bigjools> because I am passing the task's args
<bigjools> I am instantiating the task, just not executing it
<bigjools> rvba: docs.celeryproject.org/en/latest/userguide/canvas.html#signatures
<bigjools> there is a way of doing it if you use the string name for the task, but that's rather ugly IMO
<rvba> Right, using '.set(queue=foo)' is fine anyway.
<gmb> rvba: If you can re-review https://code.launchpad.net/~gmb/maas/fix-commissioning-page-distro-list-bug-1312844/+merge/222010 thatâd be great. Thanks for your help this morning, too :)
<rvba> gmb: I'll have a look now
<gmb> rvba: Ah, damn, Iâd forgotten the getZZZ() methods. Will fix that. Thanks.
<rvba> np
<jtv> "Get-some-sleep methods"?
<rvba> jtv: allenap: any idea what might be wrong? paste.ubuntu.com/7623634/
<rvba> RabbitMQ didn't got installed properly.
<jtv> "Yes you're using the mouse buttons to copy/paste from chrome"
<rvba> heh
<jtv> Hmmm...  dns delay?
<rvba> I think it's rabbitMQ not dealing well with the hostname changing or somethingâ¦
<jtv> It's been ages since I heard "DNS can take 15 minutes to propagate" so I have no idea what the status is today, but maybe we're relying on synchronicity when all we have is instantaneity?
 * rvba tries to remove and re-install it.
<allenap> rvba: Itâs not a perfect fit, but http://stackoverflow.com/questions/14659335/rabbitmq-server-fails-to-start-after-hostname-has-changed-since-first-starting has a suggestion.
<rvba> Didn't help (purging then restarting rabbitMQ)
<jtv> Different error though, no?
<rvba> No, same error.
<allenap> rvba: Did purging actually remove /var/lib/rabbitmq?
<rvba> I used `apt-get purge`.
<jtv> rvba, there's another workaround for a similar problem on: http://serverfault.com/questions/225795/error-when-installing-rabbitmq-server-on-ubuntu-10-10
 * jtv reboots
<rkdemon> HI: I was trying to install maas on another server and I see this message "Import of boot images started on all cluster controllers. Importing the boot images can take a long time depending on the available bandwidth."
<rkdemon> Is there an indication anything is happening coz I don't see the boot images ever getting to the cluster
<rkdemon> Without this I cannot add a node to the cluster even though I plan to add on VMs to the cluster ?
<rkdemon> Any clues anyone ?
<rkdemon> When a VM is added as a node to a cluster: the "status" on the node says "commissioning", what does this really mean ?
<jtv> rkdemon: to see what's going on with the downloads, have a look in /var/log/maas/celery.log... look for "import."
<jtv> A status of "commissioning" means that the node has been told to boot into a temporary environment (not installed on disk) for basic self-check and network discovery.
<jtv> Eventually it should contact the server to say that it's done commissioning (whether successfully or not) and its state should become Ready (or Failed, as the case may be).
<rkdemon> jtv: thanks
<d_`> I have a MAAS region with 2 cluster controllers in it, one is on the same node as the region controller, one is on its own node. all the machines that register against the shared role node work fine, all the nodes that are registering against the stand alone cluster controller are stuck in the declaration process booting the discovery image where it prints the route table out
#maas 2014-06-11
<bigjools> any takers? https://code.launchpad.net/~julian-edwards/maas/node-claim-static-ips/+merge/222743
<jtv> Oh what the hell.  I'll take it.
<gmb> Yay, test isolation issues!
<gmb> My favourite thing in all the world!!!1!
<bigjools> jtv: grassy ass
<mfa298> I've been asked to spec some Dell hardware for Maas + Juju + openstack and I was wondering if anyone had experience of what level of IPMI/iDrac is required for Maas - Is the basic IPMI service enough or does it need one of the iDRAC options (Express / Enterprise)
<magicrobotmonkey> I use it fine with basic ipmi
<magicrobotmonkey> all it needs is the power commands, i think
<mfa298> that's good to know. Ive only used Dells in the past with the iDRAC Enterprise but that get's pricey.
<mfa298> I was thinking the basic IPMI would work but not something I've ever used on Dells.
<jtv> blake_r: I wrote some review notes for your certificate-generating branch.  I wonder if a future version of the script shouldn't just submit the key to maas for you.
<blake_r> jtv: yeah that would be good, that was written by cloudbase, but we could add that
<blake_r> jtv: mayge with a flag
<jtv> Yeah... you'd need credentials of course, so maybe optional... later.  :)
<jtv> à¸§à¹à¸²à¸²à¸² a single test that's more than a page long...  â¹
<blake_r> Haha...
<blake_r> jtv: thanks for the review
<blake_r> jtv: lucky for me I get to fix there code! so happy!
<jtv> blake_r: I've been there and trust me, it gives me no pleasure.  :)
<jtv> (Well unless I can do it to somebody _else_ of course.  Or is that what you meant?)
<blake_r> jtv: you got it correct the first time!
<l1l> what is the best way to get nodes setup with vlans?
<l1l> if a node is declared, then attaching a network to it.. do the vlans get pushed into the preseed?
#maas 2014-06-12
<AskUbuntu> MAAS and Openstack Network | http://askubuntu.com/q/482090
<AskUbuntu> Add Nodes to MAAS for JUJU Bundle | http://askubuntu.com/q/482094
<bigjools> rvba: care to review? short one: https://code.launchpad.net/~julian-edwards/maas/static-allocation-of-existing-ips/+merge/222904
<rvba> bigjools: sure
<bigjools> cheers, bbiab, eating
<jtv> Who wants an easy review?  They might find one at https://code.launchpad.net/~jtv/maas/lint-2014-06-11/+merge/222905
<jtv> (Actually, a surprisingly large diff.  Removed a lot of trailing whitespace from documentation.)
<rvba> jtv: I'll take it
<jtv> Je vous remercie.
<jtv> Or something equally French-sounding.
<rvba> heh
<AskUbuntu> Ubuntu MAAS DHCP working DNS Not working | http://askubuntu.com/q/482313
<jpds> AskUbuntu: You can set a DNS server in the web UI.
<AskUbuntu> problem with login node on maas via ssh | http://askubuntu.com/q/482396
<sebas5384> hello!
<sebas5384> i'm starting an infrastructure project, and i would like to use Juju
<sebas5384> but because I can't use services like Amazon, i have machines already provided
<sebas5384> so i want to use maas to map them as nodes
<sebas5384> and they are VMs
<sebas5384> so, my question is, even not being a real bare metal, would be right or logic to use maas with juju in this case?
<sebas5384> or I should go with the juju manual provisioning env type?
<sebas5384> hmmm so I sow the power type virsh
<jtv> sebas5384: you can do that with maas, but it won't _create_ the vms for you.
<sebas5384> great! automating the creation of vms is another client's battle i will have in the future hehe
<sebas5384> thanks jtv :)
<sebas5384> now they are using vmware
 * jtv is away now
#maas 2014-06-13
<AskUbuntu> maas enlistment network problem | http://askubuntu.com/q/482630
<bigjools> right, any takers? https://code.launchpad.net/~julian-edwards/maas/allocate-ip-on-start-2/+merge/222747
<bigjools> static IPs are working on my test rig with this
<bigjools> it's a tad longer than I would have liked at ~650 lines, so grab tea/coffee/painkillers
<rvba> Reviewer needed! https://code.launchpad.net/~rvb/maas/dhcp-stop-bug-1328656/+merge/223049
<jtv> blake_r: re-reviewed x509-ssl-key.  Still a lot of things to do, sorry.  :(
<blake_r> jtv: its okay
<blake_r> jtv: thanks for looking at it
<blake_r> jtv: hopefully have something fixed today
<jtv> blake_r: cool...  I'd split the migration out into a separate branch.  Easier to manage, and helps avoid the sequence number being taken by someone else while you're going through review.
<blake_r> jtv: okay I will do that first
<blake_r> jtv: thanks
<jtv> Tip top, as Gav would say.
<RedCenterMAAS> help with how long to wait after a host PXE boot before they are seen by the Cluster Controller
<RedCenterMAAS> with auto discovery, my host boot PXE and look to be fine, up to a screen with ci-info and network info. But nothing seem to happen after that.
<RedCenterMAAS> how long does this info gather phase take. hours ? days ?. I've left system for about 12 hours thinking I should just wait.
<RedCenterMAAS> I've also build a test server via the CD disto to make sure that my DHCP and DNS server (ie th eMAAS  cluster crtl'er) is work. And it all id. DNS and DHCP work OK.
#maas 2014-06-15
<AskUbuntu> Where can I find a log or see the progress of importing images in MAAS? | http://askubuntu.com/q/483471
<galebba> Hi having issues setting up Maas to IPMI power on servers. Wonder where the logs to look at the state of the commissioning. No useful info in /var/log/maas
<jpds> galebba Probably best to try to power them on with the ipmitool command.
<jpds> galebba: Using the credentials in MAAS.
<galebba> so not to use the maas gui ? but i wouldnt be able to commission the node then
<jpds> galebba: You have the node in MAAS, enlisted?
<galebba> not yet, trying to register them for the first time. This is on Cisco C Series blade.
<jpds> galebba: Right, try enlisting it first.
<galebba> i can ipmiping the server
<galebba> sorry i am a newbie so this is what i am trying to do. Brought up the maas server and in the gui trying to Add Node option where i have to specify all the node info like mac/ip/ipmi credentials etc.. and it goes to commission and never moves to ready state which i am guessing is due to not being able to power on the node. I do not see an enlist option.
<jpds> galebba: Don't do that.
<jpds> galebba: Configure a DHCP server in MAAS; and make the node PXE boot.
<jpds> galebba: It'll boot, and MAAS will figure out all the IPMI stuff itself.
<galebba> i tried that as well. Configed Maas to be both dhcp and dns. webt to the node and boot from the ubuntu dvd, choose maas insatll. then manually put the maas server ip and the node was able to talk to the maas server and powered off by Maas. however the node never showed up in the mass nodes in the gui. thats why i trying to add the node manually.
<jpds> galebba: You did run: sudo maas-import-pxe-files ?
<jpds> galebba: You're suppose to PXE boot the nodes.
<jpds> Can you imagine using a DVD for 500 servers?
<galebba> yes i see the images. now from previous installs the server get powered off by the maas and the info appears in the gui for the node and then i can commission which would power on the node via ipmi and then pxe boot. nd that was on Cisco UCS B series blades. But this is on Cisco C series blades.
<galebba> newbie here, where do i look for logs for commissioning a node in maas ? Trying to get my first node up and doesnt look like maas is able to ipmi power on the node. /var/log/mass dont have any logs showing the state changes during the commissioning
#maas 2015-06-08
<mup> Bug #1431578 changed: maas is showing all interfaces with active ethernet link as connected after commissioning <oil> <MAAS:Expired> <https://launchpad.net/bugs/1431578>
<Yash> hi
<Yash> anyone there?
<mup> Bug #1463027 opened: attempt to install wily gets no curtin in user-data <MAAS:New> <https://launchpad.net/bugs/1463027>
<mup> Bug #1463027 changed: attempt to install wily gets no curtin in user-data <MAAS:New> <https://launchpad.net/bugs/1463027>
<mup> Bug #1463027 opened: attempt to install wily gets no curtin in user-data <MAAS:New> <https://launchpad.net/bugs/1463027>
<mup> Bug #1463027 changed: attempt to install wily gets no curtin in user-data <MAAS:Invalid> <https://launchpad.net/bugs/1463027>
<mup> Bug #1463176 opened:  modprobe hpvsa fails after installing hpvsa <hp> <hpvsa> <MAAS:New> <https://launchpad.net/bugs/1463176>
#maas 2015-06-09
<masumotok> Hello, I am newvie for maas, now I got an error  "maas <profie>  boot-resources  import". In /var/log/maas/maas.log, I got "[WARNING] Finished importing boot images, the region does not have any boot images available.". The http-proxy exists in my network and thus, it requires user/password authentication. I would like to set HTTP_PROXY to maas. Does anyone know how?
<masumotok> MAAS seems like not accepting "http_proxy=http://<username>:<password>/ipaddr:port" style parameter, as declared <http://askubuntu.com/questions/618657/maas-cant-download-boot-images>. Anyone know the tips?
<mup> Bug #1463378 opened: Downloaded di-initrd on trusty/amd64 overrides /etc/network/interfaces <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1463378>
<vibol> Hello!..
<vibol> I'm importing boot image on Maas but the static in web gui still in "Qeued in download"
<kiko> vibol, 1.5 or 1.7?
<vibol> er.. sorr please wait
<vibol> i'm installion from ppa:maas-maintainer/stable
<vibol> @@ anyway really sorry how to check maas version @kiko ?
<vibol> 1.7.5 @kiko
<kiko> hmm
<kiko> interesting
<kiko> vibol, are you behind a proxy?
<vibol> i'm no...
<vibol> but i notices
<vibol> some repositry of my ubuntu kinda slow
<kiko> if you look at *.log in /var/log/maas you'll get an idea of what is happening
<kiko> if there are timeouts or similar
<vibol> http://paste.ubuntu.com/11672885/
<vibol>  [INFO] Started importing boot image
<vibol> [WARNING] Finished importing boot images, the region does not have any boot images available.
<vibol> WARNING] No boot images have been imported from the region.
<vibol> Still have no idea @kiko
<kiko> vibol, the region controller downloads the images first, and then the cluster controller downloads them from the region
<kiko> vibol, so what's happening is that the region controller is unable to download the images
<kiko> vibol, can you confirm you can access the internet from the region controller machine?
<vibol> I don't have reqion controllor machine yet maybe @@
<vibol> should i install maas-region-controller etc ?
<kiko> vibol, i.e. can you go to streams.ubuntu.com https://cloud-images.ubuntu.com/releases/streams/v1/ ?
<kiko> ah
<vibol> yeb it accessable
<kiko> vibol, you probably do have the region controller package installed in a single machine then
<kiko> the region controller hosts the UI
<kiko> so if you have web UI the region controller is running
<vibol> i'm follow from ubuntu.com/cloud
<kiko> I assume you did an apt-get install maas, yes?
<vibol> yeb
<vibol> !!
<kiko> okay
<kiko> so for some reason the maas region isn't able to download images
<kiko> what does maas.host/images say?
<vibol> kiko ... but.
<vibol> "maas-region-controller is already the newest version."
<kiko> vibol, yes, you're fine
<kiko> the region is present
<kiko> so the issue is to do with the region not being able to download for whatever reason
<vibol> yeb
<kiko> vibol, was this a fresh install?
<vibol> yeb..
<vibol> first i install ubuntu server and start add ppa
<vibol> apt install maas
<vibol> i follow on http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
<kiko> okay
<vibol> in /var/log/maas
<vibol> only file apache2  maas-django.log  maas.log  oops  proxy  pserv.log  rsyslog
<vibol> are present
<vibol> i'm install ubuntu on vmware to do this...
<vibol> @kiko i'm thank for you hlep
<vibol> 80% maybe internet connection
<kiko> vibol, do you get a spinner on the /images page?
<kiko> perhaps share a screenshot?
<vibol> i have access http://maas.ubuntu.com/images/ephemeral-v2/releases/ in the log
<vibol> but i can't download any file
<kiko> vibol, oh, what happens if you download?
<vibol> server error
<vibol> it from my ips i think
<vibol> @kiko
<kiko> vibol, so that's your problem right there. I wonder why
<kiko> vibol, ah, perhaps you have a transparent proxy affecting your traffic?
<vibol> hmm i'm not really sure
<vibol> but i don't use any proxy right here
<vibol> i try to use another connection to confrim the problem but i need to be at my school lol...
<bdx> Hows it going everyone?
<bdx> I'm wondering if someone can aid me in identifying the root-path-string of the iscsi service running on maas
<bdx> ????^^^^
<kiko> bdx, hmm, maybe we can, but why do you want to know? :)
<bdx> kiko: I think I found what may work by running sudo iscsiadm -m discovery -t st -p <maas-server-ip>
<kiko> bdx, are you having to gateway the iscsi traffic? or something else?
<bdx> kiko: I am trying desperately to get maas to work with our companys existing dns/dhcp configuration
<kiko> ah.
<kiko> that is indeed a common challenge
<kiko> I'm clueless, though -- why do you need the iSCSI root-path? oh, because that's what the DHCP server needs to supply back?
<kiko> bdx, have you tried looking at the generated dhcpd.conf?
<kiko> and fragments?
<bdx> kiko: exactly
<bdx> yea....thats what I have based my external dhcp config off of
<kiko> but that's missing, is that it? it's in the host maps?
 * kiko can't remember
<bdx> I can get nodes to enlist and commission successfully
<bdx> https://www.dropbox.com/s/916u59gqoetlt7a/Screenshot%202015-06-09%2011.42.18.png?dl=0
<bdx> kiko: I'm thinking its got to be 10.16.0.2:3260,1 iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-trusty-daily
<kiko> bdx, have you tried looking at the console of a node booting? but that does look correct
<bdx> kiko: yes.... I can verify that the logs and console show the iscsi url
<bdx> I am now thinking because the node enlists and commissions, that iscsi-root-path might not even be my issue
<kiko> okay, try kicking off a run and seeing if it works
<bdx> my bad
<bdx> yea
<bdx> I am at a total loss
<bdx> I have been trying at this for quite a while...like a few weeks
<kiko> wow, you should have come asking for help earlier!
<kiko> anyway, tell us where you are stuck next
<bdx> kiko: so...I can successfully enlist and commission nodes in maas
<bdx> I am using pfsense for dhcp and have it configured to update my dns when it hands out addresses
<kiko> so far so good
<kiko> what's up with deploying?
<bdx> kiko: when I deploy a node that is in "ready" state in maas, the node seems to commission itself, and power off....soon after I get a "deployment failed" status
<kiko> bdx, okay, you need to look at the node log or console to see what's up
<bdx> kiko: Ok...the console shows that of commissioning a node
<kiko> well, you're not commissioning any more
<kiko> now you're deploying
<kiko> commissioning doesn't touch the drives
<bdx> yea....but the node is commissioning when I try to deploy
<bdx> ok
<kiko> ah
<kiko> that is an interesting hint
<kiko> blake_r, what do we supply to the node when we are deploying in terms of iscsi path?
<kiko> bdx, if you can find that out (do you have a parallel install with managed dhcp/dns) then we don't need to wait for blake_r
<blake_r> kiko: the DHCP or DNS server does not provide this information, it comes from the PXE request
<blake_r> kiko: that information is sent to the linux kernel using kernel parameters in the pxelinux.cfg that the server requests once it loads pxelinux.0
<kiko> blake_r, okay, so we basically write out a pxelinux.cfg that is specific to commissioning or deployment?
<blake_r> kiko: its includes the maas server ip address and the iscsi target to mount
<kiko> blake_r, I wonder if bdx is trying to do something he doesn't need to
<blake_r> kiko: yes it is specific, based on the state of the node and the node
<kiko> gotcha
<kiko> bdx, ^^
<bdx> kiko, blake_r: what could this indicate in my situation?
<kiko> bdx, where are you putting the iscsi target and why?
<bdx> kiko: no where yet
<kiko> bdx, how do you know it's commissioning instead of deploying?
<bdx> kiko, blake_r: because the console shows what it shows when I commission a node
<blake_r> bdx: commissiong and deploying look the same watching the console of the node, its very similar
<blake_r> bdx: they both load ubuntu over pxe
<bdx> totally....I have been using maas for dhcp/dns in my test lab for a while...I'v watched the commissioning and boot console many a time:-)
<bdx> I am now trying to move the setup to our production environment where external dhcp/dns must be used
<kiko> bdx, can you take a screenshot of the console in both commissioning and deployment so we can spot the issue?
<kiko> ideally including what pxelinux is doing
<kiko> perhaps that's more like a movie :)
<bdx> kiko, blake_r: I can't say for sure that the node is "commissioning" instead of "deploying".....the console just shows the output of a commissioning ....but it could be a deploy that gets interrupted im thinking
<kiko> yes
<kiko> though the console will tell you what is going wrong -- i.e. for instance, the node is unable to download packages, etc
<bdx> yeah....give me a minute....what is easiest...periscope, meerkat, youknow?
<bdx> I guess youtube probably
<kiko> I don't actually know, but it needs to be readable 8)
<bdx> ok....I'll take a video ...give me 5
<kiko> sure
<bdx> kiko, blake_r: here is a video of a node commissioning https://files.darkhorse.com/_RLGdv3A9r2RStR
<bdx> kiko: blake_r: here is a deployment https://files.darkhorse.com/_vZGMW6SjX2lSPR
<kiko> bdx, hmm, so slow for me to download.. 10 mins!
<bdx> iphone -> hdvideo
<bdx> ill render them smaller here
<bdx> https://files.darkhorse.com/_rWG14-Ti-23SnR
<bdx> https://files.darkhorse.com/_GQH8XCCdS2FS5R
<kiko> 2/3 gone, now I will wait!
<bdx> lol
<blake_r> bdx: the extract of the image failes
<blake_r> bdx: check MAAS you should have an installation log
<blake_r> bdx: on the node details page
<blake_r> bdx: it will give you the error
<bdx> omg I've overlooked the install log button for so long....grrr
<blake_r> 10.0.3.1 is that your MAAS server address that a node can access?
<blake_r> bdx: says no route to host
<bdx> no...that is a lxcbr0 created by juju....omg the install log shows all
<bdx> http://paste.ubuntu.com/11678270/
<bdx> I wonder why it is trying to use that
<blake_r> sudo dpkg-reconfigure maas-cluster-controller
<blake_r> check that
<kiko> yep
<bdx> it is set correctly to "http://10.16.0.2/MAAS"
<kiko> bdx, does grep 10.0.3.1 /etc/maas return anything?
<blake_r> I think maas gets that ip address from the initial PXE request from the client
<bdx> possibly I should just delete the unused interface for 10.0.3.0/24 in my cluster interfaces
<blake_r> it looks at the ip address the request comes in on
<blake_r> is it routed through the bridge?
<bdx> https://www.dropbox.com/s/8re057l9pgw8guj/Screenshot%202015-06-09%2012.38.40.png?dl=0
<kiko> blake_r, that can't make sense, the video shows the node booting on the 10.16 network no?
<kiko> 10.16.0.115 is the IP it got, the server is 10.16.0.4
<kiko> bdx, does grep 10.0.3.1 /etc/maas return anything?
<blake_r> kiko: ah no I am wrong
<blake_r> kiko: this actually comes from the region
<kiko> ah
<blake_r> kiko: its because he has it them all set to unmanaged
<blake_r> kiko: the region is then trying to say okay from this node, where should we say to get the images
<bdx> kiko, blake_r: I removed lxcbr0 - 10.0.3.0 net from the maas server a while ago.... although it looks like I never removed it from the maas cluster interfaces
<blake_r> kiko: since noe are managed it just makes the best guess.....
<bdx> kiko, blake_r: I should probably remove 10.0.3.0 from my cluster interfaces and retry a deploy yea?
<kiko> blake_r, of course
<blake_r> kiko: which is not the correct guess
<blake_r> bdx: yes
<kiko> bdx, how do we tell maas to give it this interface, specifically :)
<blake_r> kiko: the region does it best, but since its not managing the DHCP it cannot determine what ip address this node has, since the DHCP is not managed by maas
<bdx> kiko, blake_r: seeing as the interface is unmanaged and it never posed an issue while maas was managing dns/dhcp....I guess I never payed it any attention
<blake_r> bdx: just delete all interfaces, except the one you want the nodes to communicate on
<bdx> done.
<blake_r> bdx: yeah I bet that will work for you, let me know
<bdx> will do... omp
<bdx> blake_r, kiko: It worked
<blake_r> bdx: great!
<bdx> :-):-)
<bdx> I am so releived...this has been plaguing me....and to think the install log was starring me in the face the whole time
<bdx> kiko, blake_r: THANK YOU
<bdx> x10
<bdx> x1000
<blake_r> bdx: your welcome
<bdx> kiko, blake_r: It seems the node was given the hostname "ubuntu"
<bdx> kiko, blake_r: Is this something I should resolve with a cloud-init post-deploy config script or a modification to the preseed?
<blake_r> bdx: no cloud-init and maas already do that for you
<blake_r> bdx: it should get the same name as the name in MAAS
<blake_r> bdx: are you able to ssh in to the machine?
<blake_r> bdx: cloud-init might have failed
<bdx> yeah...by hostname
<bdx> ssh ubuntu@ubuntu.tfawint.com
<blake_r> on the machine is the hostname "ubuntu" or just in your dns server?
<blake_r> whats the output of hostname on the server?
<bdx> ahhh...when I ssh into the machine it shows its hostname from maas....just dns gets an entry for ubuntu.tfawint.com instead of excited-battle.tfawint.com
<blake_r> yeah that is something to do with your dns server then
<blake_r> since your not using maas dns
<bdx> I see....the dns server was getting the correct fqdn entries created when a node commissions
<blake_r> that is probably because the server DHCP before it sets it hostname
<blake_r> it needs an IP address before it can contact MAAS for cloud-init data
<blake_r> a reboot of the server might fix your DNS server
<bdx> totally....I'll reboot all servers and see what I can't figure out on my own.....I'll let you guys know if I get stuck again.....thanks again for your help
<bdx> blake_r: rebooting the deployed node forced the correct entry to be created with the correct fqdn!
<blake_r> bdx: awesome
<kiko> bdx, cool, happy you sorted it out
<kiko> blake_r, should I file a bug to cover that use case? it is so obvious in hindsight
<blake_r> kiko: yeah
<kiko> krad
<kiko> blake_r, do you know where the code that "guesses" the interface is?
<kiko> blake_r, I'm trying to get some context to help me file a bug summary with less than 200 lines
<blake_r> kiko: yep
<blake_r> kiko: one second
<blake_r> kiko: http://bazaar.launchpad.net/~maas-committers/maas/trunk/view/head:/src/maasserver/preseed.py#L588
<kiko> how about
<kiko> "Deploying from a multi-homed cluster controller with external DHCP/DNS fails by giving the machine the wrong IP for the cluster controller"
<kiko> that comment is interesting
<blake_r> multi-homes? I would say, "with multiple unmanaged interfaces"
<bdx> blake_r, kilo: wow, so the multiple unmanaged interfaces is a documented bug then?
<bdx> kiko*
<kiko> not documented yet
<kiko> but soon :)
<kiko> bdx, I'm curious why a machine on 10.16.0.0 couldn't reach the lxcbr0 interface. was it firewalled off?
<kiko> oh, it doesn't route though the cluster controller, that's why
<bdx> kiko: I had deleted lxcbr0 a while back...it hasn't existed for > 2 months
<bdx> at the os level
<kiko> I see
<kiko> is the cluster controller the router?
<kiko> if it isn't, it wouldn't have worked anyway :)
<bdx> no....I have vlans trunked in on my maas-controller eth0....from when I was trying to deploy openstack and use multiple nets.
<bdx> kiko, blake_r: unfortunately I have not had any luck deploying anything when using > 1 interface managed by maas
<kiko> bdx, interesting, that may be yet another bug
<mup> Bug #1463555 opened: Deploying from a multi-homed cluster controller with external DHCP/DNS fails by giving the machine the wrong IP for the cluster controller <MAAS:New> <https://launchpad.net/bugs/1463555>
<blake_r> bdx: can you give more detail information on what you mean?
<bdx> kiko, blake_r: My workaround was to use external dhcp for all nets that maas was not managing.
<kiko> bdx, blake_r: it may stem from the same naive algorithm that code uses
<blake_r> kiko: maybe'
<kiko> it seems to think it's a good idea to search through the IPs on the cluster
<blake_r> bdx: can you give an example configuration
<kiko> instead of trying to match the IP the node is asking on
<kiko> that's a recipe for badness
<blake_r> kiko: yeah we actually know the ip address the node is requesting on the cluster, that just needs to be passed to the region to generate the preseed
<kiko> exactly
<kiko> blake_r, add a comment to that effect in the bug maybe
<kiko> and bdx your comments welcome as well
<bdx> kiko, blake_r: Lets say I have storage nodes that need secondary interfaces on a replication net....If I were to add maas managed dhcp on the net which the nodes secondary interface lives...in order to have that interface get an ip when the node boots ....
<bdx> kiko, blake_r: enlistment and commissioning completely fail
<bdx> kiko: thanks
<blake_r> bdx: so you have MAAS providing DHCP on two interfaces? in different subnets, and that fails if a node is on both those interfaces?
<blake_r> bdx: do you have any logs or anything for this error?
<bdx> blake_r: true true
<bdx> blake_r: I could have them fairly easily
<blake_r> bdx: that would be helpful, if you could file a bug with that information
<bdx> blake_r, kiko: I'll file a bug concerning that issue.....I feel this is one of the biggest disconnects between juju <-> maas. Juju encourages through charm config params the use of multiple networks in many charms
<kiko> right, which MAAS doesn't get very right
<kiko> blake_r, again, I think it may stem from the same bad code
<bdx> true
<kiko> if we try and hunt through interfaces without taking into account the requesting IP..
<kiko> okay I need to split
 * kiko waves
#maas 2015-06-10
<dweaver> I'm having a problem in MAAS 1.7.5+bzr3369-0ubuntu1~trusty1 enlisting a Dell poweredge R630 that reports there to be no valid network device during ifconfig and hence can't mount the root device over the network.
<dweaver> The machine presents NICs as em1, em2 rather than eth0,eth1.
<dweaver> Screenshots here: https://dl.dropboxusercontent.com/u/478290/tmp/Photo%2010-06-2015%2010%2034%2016.jpg
<dweaver> and https://dl.dropboxusercontent.com/u/478290/tmp/Photo%2010-06-2015%2010%2034%2034.jpg
<dweaver> anyone got any idea what is happening here?
<dweaver> Traced it to the intel i40e card and a problem with loading the driver.  Looks like the firmware needs an update.
<dweaver> However, diging into this I saw that the enlistment preseed has a hard coded ethernet interface (eth0) which may or may not be the case, e.g. em1,em2 etc.  shouldn't the NIC device be detected rather than assume eth0?
<kiko> heya dweaver!
<kiko> great to see you around
<kiko> dweaver, yes, and that strikes me as a bit odd as I think we work with other NIC names
<kiko> dweaver, can you point me to the preseed code so I can get somebody to look at it?
<roaksoax> dweaver: good cathc. That's an old piece of code that was used to auto-determine the DNS of the machine, but in fact, now it is deprecated. That being said, it should not affect the enlistment process at all. Do you have console logs?
<roaksoax> dweaver: a good test would be for you to remove that line of code (and set ip="") and see whether the machine enlists or not
<roaksoax> dweaver: in fact, you can simply delete the whole ip=XYZ
<kiko> roaksoax, will you file a bug or drive-by?
<kiko> roaksoax, also, I think dweaver traced the issue to a firmware bug
<dweaver> kiko, Yep, traced it to a firmware bug, I think, rather than a problem with the preseed.  I found the code in the preseed because I was looking for any references to eth0 in the /etc/maas directory, but as roaksoax says it is unused code now, so no need to raise a bug unless we determine a different cause.
<kiko> dweaver, the bug should be raised to kill that code I think :)
<dweaver> OK, then, I'll raise a bug then ;)
<roaksoax> dweaver: please do!
<dweaver> roaksoax, thank you for the help
<roaksoax> dweaver: thank you for spotting that one
<Mmike> Hi, guys. How do I change apt-cache information that curtin puts into 90curtin-aptproxy? I don't want to use MAAS provided squiddeb but want to use my local apt mirror.
<Mmike> that is in relation to https://bugs.launchpad.net/maas/+bug/1460151
<kiko> Mmike, hmm
<Mmike> kiko, I'm looking for some template file or something, inside /etc/maas, to change, but I'm not finding any...
<kiko> Mmike, that's a weird bug, but we should definitely make sure we don't step on each other
<kiko> Mmike, do you have a proxy configured in maas' settings?
<Mmike> sec, let me see
<kiko> Mmike, also, do you have maas-proxy installed?
<Mmike> kiko, in fact I do (have configued http proxy in maas' settings)
<Mmike> yup, I have maas-proxy, 1.7.2+bzr3355-0ubuntu1~trusty1
<kiko> Mmike, I am just wondering if you could remove that config and possibly remove the maas-proxy package
<kiko> Mmike, if you could and it resolves your issue, it's a valid workaround
<kiko> Mmike, maybe do one and then the other, if that makes sense
<Mmike> kiko, I'll sping up local maas server and try it out
<Mmike> will let you know
<Mmike> just need to get rid of damn btrfs, it's unusable for kvm images
<Mmike> s/sping/spin
<kiko> Mmike, what kernel version are you having btrfs issues with, just curious?
<kiko> Mmike, I use it too
#maas 2015-06-11
<mup> Bug #1464281 opened: 1.8rc3: Incorrect IP Address label in UI (dynamic) under Network->IP for previous static IP address. Deployment gets static IP <oil> <MAAS:Incomplete> <MAAS 1.8:New> <MAAS 1.9:New> <https://launchpad.net/bugs/1464281>
<mup> Bug #1464320 opened: Timezone support is unclear <MAAS:New> <https://launchpad.net/bugs/1464320>
<Daniel_> Hi
<kiko> hey
<Daniel_> I'm trying to add a node to my cluster (virtualized on my laptop). I'm trying to boot a Proliant dl360. If I choose the default installer, MaaS install the system properly but after that I can't deploy anything from juju (agent: pending)
<Daniel_> If I chose the fast installer, the node gets into a bootloop... I can see the node in MaaS and in Juju. One time I was able to bootstrap juju to the proliant, with default installer enabled
<Daniel_> anyone can help me?
<Daniel_> and when I manage to get the proliant working and it's showed in Juju, I run juju add-machine but nothing happens, even in the logs. But I'm still thinking the problem comes with MaaS and this bootloop
<Guest19502> how can I see old messages? I lost my internet connection and they are  all gone :(
<roaksoax> /win/win 13
#maas 2015-06-12
<lathiat> Turns out enabling the openstack kilo ubuntu repository on my maas controller was a mistake, upgrades twisted and hits https://bugs.launchpad.net/maas/+bug/1431741
<kiko> lathiat, 1.7 right?
<kiko> yeah
<kiko> rvba, why is that only fix committed? did it not go into 1.7?
<kiko> lathiat, can you apply that patch live and does it fix the issue?
<rvba> kiko: it doesn't seem that fix is in 1.7.  But AFAIUI MAAS 1.7 doesn't target platforms with Django 1.7.
<mup> Bug #1464701 opened: Deselected filter left with stray underline <landscape> <MAAS:New> <https://launchpad.net/bugs/1464701>
<lathiat> kiko: well, no, 1.5 from the 14.04 repos.
<lathiat> probably not the end of the world since i dont actaully need that repo on th emachine
<lathiat> i did it trying to find cloud-archive:tools for 14.04 which it turns out doesn't exist
<kiko> lathiat, yeah -- could you move to 1.7?
<lathiat> kiko: is there a ppa for it?
<lathiat> i looked but coldn't find mention in the docs
<kiko> lathiat, yes, I think it's mentioned in the topic
<lathiat> ahh https://launchpad.net/~maas-maintainers/+archive/ubuntu/stable
<kiko> yep
<lathiat> are docs bugs file dinto launchpad?
<lathiat> the current docs say to use ubuntu-cloud:archive, saying it has the latest lts release support
<kiko> yep!
<lathiat> btu that archive only supports 12.04
<kiko> bugs.launchpad.net/maas
<lathiat> so that could be updated
<lathiat> i will try that repo out thanks
<mup> Bug #1464720 opened: commit_within_atomic_block is depreacted <MAAS:Triaged> <https://launchpad.net/bugs/1464720>
<mup> Bug #1464741 opened: 1.8.0 unable to rename machine <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1464741>
<mup> Bug #1464741 changed: 1.8.0 unable to rename machine <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1464741>
<mup> Bug #1464741 opened: 1.8.0 unable to rename machine <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1464741>
<Mmike> kiko, responded to https://bugs.launchpad.net/maas/+bug/1460151
<Mmike> kiko, when I want to remove maas-proxy, everything gets removed (maas, maas-dns, maas-region-controller)
<Mmike> kiko, btw, re: btrfs - I was using it only for lxc provisioning - got an separate ssd just for lxc, and it was workingok. Then I got another SSD, and did mkfs.btrfs -d raid0 over both of them. Then I started to experience slowdowns after a week or two of usage (btrfs-transactio process was hammering the drives in the background).
<Mmike> The other day I got another 2 SSDs (so I can have 4 of them in raid0-like config) and that killed btrfs performance completely. The slowdowns were frequent - for instance deploying mongodb charm in lxc took over 20 minutes (mongodb creates large oplog files, and I guess those don't play well with COW filesystem)
<Mmike> Also, qcow2 images on btrfs is also no-no. raw images work a tad better, but also very very slow. I now reverted to lvm on mdraid0 over those 4 ssds (I actually didn't need mdraid0 as lvm can do that by itself), and the performance is superb.
<Mmike> fio test gives me over 40MB/sec in troughput in 16job random readwrite test over 8GB file. (On btrfs I had cca 900k/sec)
<Mmike> kiko, that's all on trusty kernel (3.13)
#maas 2015-06-13
<mup> Bug #1464864 opened: enlist_userdata determines host from eth0 only <MAAS:New> <https://launchpad.net/bugs/1464864>
<mup> Bug #1464866 opened: Unable to commission node which needs hwe kernel on trusty <MAAS:New> <https://launchpad.net/bugs/1464866>
<mup> Bug #1464867 opened: dhcpd dns server unable to modify <MAAS:New> <https://launchpad.net/bugs/1464867>
<mup> Bug #1464867 changed: dhcpd dns server unable to modify <MAAS:New> <https://launchpad.net/bugs/1464867>
<mup> Bug #1464867 opened: dhcpd dns server unable to modify <MAAS:New> <https://launchpad.net/bugs/1464867>
<mup> Bug #1464894 opened: Crash in TFTP server code serving UEFI boot loader <MAAS:New> <https://launchpad.net/bugs/1464894>
#maas 2015-06-14
<mup> Bug #1464984 opened: Crash in TFTP server booting NUC under UEFI <MAAS:New> <https://launchpad.net/bugs/1464984>
<mup> Bug #1464989 opened: MAAS fails to install on UEFI NUC with curtin bcache error <MAAS:New> <https://launchpad.net/bugs/1464989>
<mup> Bug #1465000 opened: MAAS TFTP fails when MAAS interface is not the default route device <MAAS:New> <https://launchpad.net/bugs/1465000>
<mup> Bug #1465071 opened: Daily hwe-v kernel for trusty results in kernel panic when attempting to mount iscsi partition <MAAS:New> <https://launchpad.net/bugs/1465071>
#maas 2016-06-13
<mup> Bug #1555236 changed: Spurious test failure in TestRegionServer.test_register_calls_refresh_when_needed <tests> <MAAS:Won't Fix> <https://launchpad.net/bugs/1555236>
<tzoun0> hello!
<tzoun0> how can I make all my nodes to have the same time & date?
<mup> Bug #1591958 opened: Commisioning fails on machines without HW virtualization <MAAS:New> <https://launchpad.net/bugs/1591958>
<mup> Bug #1591958 changed: Commisioning fails on machines without HW virtualization <MAAS:New> <https://launchpad.net/bugs/1591958>
<mup> Bug #1591958 opened: Commisioning fails on machines without HW virtualization <MAAS:New> <https://launchpad.net/bugs/1591958>
<shewless> Hi there. Trying to install maas 2.0.0 on a system that has previously had maas running (used apt remove maas and autoremove initially). getting this errror: http://paste.ubuntu.com/17290298 any ideas?
<shewless> in a nut shell: psycopg2.OperationalError: FATAL:  password authentication failed for user "maas"
<Guest7817> hello there
<Guest7817> I need a help, i m a newbie
<Guest7817> i have three old computers at home. wants to connect them and make a high performance cluster. will MAAS allow me to handle such old hardwares?
<shewless> i ran purge maas-dns based on some previous bug reports and that worked.. couldn't just do maas..
<shewless> maas is great.. once it works.. just don't change the IP addresses :)
<shewless> Hi guys. I have 14.04 and 16.04 images downloaded but I can't change the default commisioning image to 16.04.  only 14.04 is an option. Maas 2.0.0.0
<shewless> hmm.. seemed to show up after about 10 more minutes.. I guess ignore. THanks
<kiko> shewless, we're working to make it more obvious when we are downloading and processing images
<shewless> kiko: that's good. Currently I use bmon to monitor the network traffic as my progress bar :)
<roaksoax> shewless: you can monitor the events too
<roaksoax> shewless: while stuff is happening , cloud-init sends status messages to maas
<shewless> roaksoax: I'm talking about downloading images to the maas controller
<roaksoax> shewless: ah! MAAS shows progress
<shewless> roaksoax: it shows a spinning wheel thing I guess..
<roaksoax> shewless: yeah if you hover on it it will give you progress
<roaksoax> shewless: but since that page is YUI, it won't update automaticlaly
<roaksoax> shewless: you you will have to F5 to refresh
<shewless> roaksoax: interesting.. next time I download an image I guess I'll have to try that.
<kiko> shewless, when that page is no longer YUI you'll have a better way of tracking updates
<mup> Bug #1592051 opened: [arm64] [beta6] auto enlistment on arm64 hardware not getting power parameters with ipmi <MAAS:New for newell-jensen> <https://launchpad.net/bugs/1592051>
<mup> Bug #1592132 opened: [2.0b7] Enlisting output returns objects <MAAS:Confirmed> <https://launchpad.net/bugs/1592132>
<mup> Bug #1592132 changed: [2.0b7] Enlisting output returns objects <MAAS:Confirmed> <https://launchpad.net/bugs/1592132>
<mup> Bug #1592132 opened: [2.0b7] Enlisting output returns objects <MAAS:Confirmed> <https://launchpad.net/bugs/1592132>
<mup> Bug #1592137 opened: [2.0b7] Can't sort IP addresses under a subnet details page <MAAS:Confirmed> <https://launchpad.net/bugs/1592137>
<mup> Bug #1592137 changed: [2.0b7] Can't sort IP addresses under a subnet details page <MAAS:Confirmed> <https://launchpad.net/bugs/1592137>
<mup> Bug #1592137 opened: [2.0b7] Can't sort IP addresses under a subnet details page <MAAS:Confirmed> <https://launchpad.net/bugs/1592137>
<bdx> blake_r_: do you have a maas-rack charm in the works somewhere I can check out?
<bdx> blake_r_: just found it in your namespace:-)
#maas 2016-06-14
<roaksoax> bdx: it is in the works,he just hasn't given it more work since the midcycle
<roaksoax> bdx: argh, since a few weeks ago
<mup> Bug #1592197 opened: [beta7] No longer can access MAAS user button (top right corner) <MAAS:Triaged by newell-jensen> <https://launchpad.net/bugs/1592197>
<bdx> roaksoax: thanks
<mup> Bug #1592206 opened: [2.0b7-pre] Tooltips pop up too aggressively and impair UX <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1592206>
<mup> Bug #1592206 changed: [2.0b7-pre] Tooltips pop up too aggressively and impair UX <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1592206>
<mup> Bug #1592206 opened: [2.0b7-pre] Tooltips pop up too aggressively and impair UX <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1592206>
<mup> Bug #1592246 opened: maas-rack register makes up a new hostname <MAAS:New> <https://launchpad.net/bugs/1592246>
<mup> Bug #1592282 opened: Adding rack controller instructions could be in the GUI <MAAS:New> <https://launchpad.net/bugs/1592282>
<jojden> http://askubuntu.com/questions/786847/vm-not-listing-in-the-maas
<Truemen> I need support in adding UCS chassis into MAAS using power-type as ucs manager
<mup> Bug #1592474 opened: Spurious failure in TestMachineFilesystemgroupListener.test__calls_handler_with_update_on_update <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1592474>
<gimmic> is there any way to 'lock' a node once it is successfully deployed and in production?
<gimmic> say I want it to be a little more difficult to release / redeploy than a simple set of clicks
<mup> Bug #1592540 opened: maas-dhcp-2.0.0b3+ does not start missing dhcpd.conf dhcpd-interfaces /run/maas not writable by dhcpd <dhcp> <packaging> <MAAS:New> <https://launchpad.net/bugs/1592540>
<kiko> gimmic, that's a great feature request
<kiko> gimmic, could you file a bug on it so I can get it on the roadmap?
<mup> Bug #1592540 changed: maas-dhcp-2.0.0b3+ does not start missing dhcpd.conf dhcpd-interfaces /run/maas not writable by dhcpd <dhcp> <packaging> <MAAS:Won't Fix> <https://launchpad.net/bugs/1592540>
<mup> Bug #1592540 opened: maas-dhcp-2.0.0b3+ does not start missing dhcpd.conf dhcpd-interfaces /run/maas not writable by dhcpd <dhcp> <packaging> <MAAS:Won't Fix> <https://launchpad.net/bugs/1592540>
<mup> Bug #1592540 changed: maas-dhcp-2.0.0b3+ does not start missing dhcpd.conf dhcpd-interfaces /run/maas not writable by dhcpd <dhcp> <packaging> <MAAS:Won't Fix> <https://launchpad.net/bugs/1592540>
#maas 2016-06-15
<jojden> http://askubuntu.com/questions/786847/vm-not-listing-in-the-maas
<mup> Bug #1592666 opened: curtin mirror URL contains double slash (/) after mirror hostname, impacting proxy cachability <MAAS:New> <https://launchpad.net/bugs/1592666>
<mup> Bug #1592703 opened: Error: "could not find kernel image: ubuntu/amd64/generic/xenial/no-such-image/boot-kernel" <MAAS:New> <https://launchpad.net/bugs/1592703>
<mup> Bug #1592757 opened: MAAS 1.9+ not picking up Mellanox ConnectX-4_EN 2x25Gbe card  <MAAS:New> <https://launchpad.net/bugs/1592757>
<mup> Bug #1592843 opened: MAAS + IPAM <MAAS:New> <https://launchpad.net/bugs/1592843>
<gimmic> kiko: would that be a blueprint or a regular bug for a feature request?
<kiko> gimmic, regular bug is fine for tracking, I can create a spec later out of it with an end-user reference
<gimmic> https://bugs.launchpad.net/maas/+bug/1453878
<gimmic> looks like one already exists
<gimmic> I'd really like to tshoot the partitioning issues w/ ubuntu 14.04 LTS
<gimmic> seems to affect regardless of LVM / raid / etc use
<kiko> thanks for the bug reference
<gimmic> I can work around it, but the deployment clearly doesn't work as intended
<kiko> gimmic, yes, agree. did you see that smoser gave you some guidance on that?
<gimmic> ah, I'll check it next time I fire up a node
<smoser> https://gist.github.com/smoser/2610e9b78b8d7b54319675d9e3986a1b
<smoser> ^
<kiko> smoser, oh!
<gimmic> even better
<kiko> smoser, nice!
<mup> Bug #1592885 opened: Date and time format should be consistent accross logs <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1592885>
<mup> Bug #1592907 opened: [2.0b7] Network interface configuration and rack controller failures <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1592907>
<mup> Bug #1592915 opened: [xenial][maas beta6][arm64] maas installs to USB drive if it is present instead of SSD <MAAS:New> <https://launchpad.net/bugs/1592915>
<kiko> ha ha ha
<kiko> I could see that one coming with the fd0 commissioning thing
<kiko> I bet it even happens with 1.9 or do we blacklist?
<kiko> also.. isn't USB fair game? :)
<mup> Bug #1592907 changed: [2.0b7] Network interface configuration and rack controller failures <cdo-qa> <MAAS:Invalid by newell-jensen> <https://launchpad.net/bugs/1592907>
<mup> Bug #1592954 opened: [2.0b7]  Service 'maas-proxy' failed to reload after fresh install <MAAS:New> <https://launchpad.net/bugs/1592954>
<mup> Bug #1592994 opened: MAAS end point cannot be added "HTTP 410 Error Gone" <cdo-qa> <cdo-qa-blocker> <landscape> <Landscape Server:Opinion> <MAAS:New> <https://launchpad.net/bugs/1592994>
#maas 2016-06-16
<axisys> any way to import the image from local disk to my VM MAAS running on VirtualBox on same bridge network
<axisys> Marco has sudo maas-import-isos in http://marcoceppi.com/2012/05/juju-maas-virtualbox/ .. but i dont have that option on 14.04
<valeech> Running MAAS Version 2.0.0 (beta3+bzr4941) - maas is running and assigning IP addresses via DHCP. I PXE boot a node, it gets an IP address but then just stops and moves on to the next boot option with a âTFTP .â Any ideas what I am missing? It looks like maas is not setting a TFTP server for the PXE client to get tht image from
<axisys> what do I configure maas dhcp on the virtualbox VM MAAS controller? I am guessing I need to add a second interface on host-only network and use that network subnet to make sure I dont break my host dhcp network?
<axisys> wish it were explained anywhere in the internet..
<axisys> so much for the claim in the /topic ;-)
<mup> Bug #1592994 changed: MAAS end point cannot be added "HTTP 410 Error Gone" <cdo-qa> <cdo-qa-blocker> <landscape> <Landscape Server:Opinion> <MAAS:Won't Fix> <https://launchpad.net/bugs/1592994>
<mup> Bug #1592757 changed: MAAS 1.9+ not picking up Mellanox ConnectX-4_EN 2x25Gbe card  <MAAS:Invalid> <https://launchpad.net/bugs/1592757>
<mup> Bug #1593219 opened: [CI] test_create_dynamic_range sometimes fails in CI <MAAS:New> <https://launchpad.net/bugs/1593219>
<mup> Bug #1567249 opened: If rack and region have different versions, the error is uninformative and confusing <MAAS:Confirmed> <https://launchpad.net/bugs/1567249>
<mup> Bug #1593334 opened: Subnet add errors out on data valication <MAAS:New> <https://launchpad.net/bugs/1593334>
<mup> Bug #1593344 opened: [2.0b8] Dropdown shadow's have disappeared and dropdown mixes with background <ux> <MAAS:Confirmed for ricgard> <https://launchpad.net/bugs/1593344>
<mup> Bug #1593334 changed: Subnet add errors out on data valication <MAAS:Invalid> <https://launchpad.net/bugs/1593334>
<mup> Bug #1593377 opened: MAAS should recheck power status if it thinks a node is already on when commissioning/deploying <MAAS:New> <https://launchpad.net/bugs/1593377>
<ildar> hi! anybody here?
<ildar> I wonder: 2.0.0 doesn't have Clusters
<ildar> so configuring interfaces became tricky
<ildar> or not?
<roaksoax> ildar: not really ?
<roaksoax> ildar: what are you trying to do?
<ildar> I just don't see howto set intterfaces
<roaksoax> ildar: what do you mean by "set interfaceS"
<ildar> in my case I have ens9 for provisioning
<roaksoax> ildar: which is why I'm wondering what are you trying to do
<ildar> but I don't see how do I tell MAAS it is ens9
<roaksoax> ildar: http://maas.ubuntu.com/docs2.0/rack-configuration.html#enabling-a-dhcp-on-a-vlan-optional-ha
<ildar> Network tab doesn't show anything about ens9
<ildar> I made a vlan
<ildar> but how it would find on which interface it is?
<kiko> ildar, that comment is weird. a tagged vlan is created from a raw interface.
<ildar> hm. I have untagged interface
<ildar> then what do I do? "Provide DHCP" ?
<kiko> ildar, yes, basically
<kiko> ildar, so ens9 is.. the interface on the MAAS cluster controller, yes?
<kiko> if so
<kiko> what VLAN is it connected to
<ildar> yes
<kiko> and what network is it?
<kiko> anyway, you just go to the VLAN and you serve DHCP on it
<ildar> no vlans configured. Plain interface
<kiko> if the cluster controller has an interface on that VLAN it will serve
<kiko> ah
<kiko> there is a nomenclature collission
<kiko> err
<kiko> colission
<kiko> go to the networks tab
<kiko> is there a vlan listed there?
<kiko> does it look sane?
<kiko> in the networks tab, where you read VLAN, think of it as a "L2 segment"
 * kiko hears clicking clicking clicking
<ildar> :)
<ildar> 1 sec
<ildar> ahh, I have my lab lagging
<ildar> sorry
<ildar> http://paste.ubuntu.com/17408804/
<ildar> http://paste.ubuntu.com/17408831/
<ildar> I created deploy-net, thought fabric-0 was autocreated.
<ildar> deleting deploy-net now
<ildar> so the fabric looks empty
<mup> Bug #1593388 opened: Changing a boot source URL while images are being download doesn't interrupt current downloads to use the new URL <MAAS:New> <https://launchpad.net/bugs/1593388>
<ildar> Hm, I see. I seem to missed rack-controller registration
<ildar> though the maas.io/get-started appears to be very misleading
<ildar> I'll try the procedure, thanks for guiding
<kiko> yeah, that doc needs a serious update
<ildar> can't get MAAS see itself as a controller
<ildar> :(
<ildar> did that "$ sudo dpkg-reconfigure maas-rack-controller", no luck
<ildar> still have "0 Controllers"
<kiko> roaksoax, ^^ ?
<ildar> hm
<ildar> I see regiond.log polluted with http://paste.ubuntu.com/17410850/
<ildar> 44M , too much
<kiko> it's a bug jim
<kiko> mpontillo, ^^
<kiko> ildar, 1.9 or 2.0?
<ildar> 2.0.0
<ildar> MAAS Version 2.0.0 (beta3+bzr4941)
<kiko> ildar, could you update to the latest beta first?
<ildar> it's the latest available from ppa
<kiko> is not!
<kiko> https://launchpad.net/~maas/+archive/ubuntu/next
<ildar> at least it is two days old, not more
<mpontillo> ildar: beta 7 should be available in ppa:maas/next
<kiko>  2.0.0~beta7+bzr5112-0ubuntu1~xenial1
<ildar> ahhh
<kiko> what PPA are you using?
<ildar> I see
 * kiko frowns
<ildar> ppa:maas/stable
<ildar> should be stable and workable :)
 * kiko updates the description of experimental
<mpontillo> ildar: MAAS is still in beta on Xenial; there is no stable version per se. I think beta 3 is what ended up in the archive when Xenial was shipped
<ildar> :)
<ildar> ok
<mpontillo> ildar: it should be quite usable though; we are nearing a release candidate based mostly on beta 7
<kiko> ildar, you are joking about maas/stable I think
<ildar> but I can't update right now
<kiko> as 2.0 is not in that PPA
<kiko> you are using maas-maintainers/experimental
<kiko> which has been deprecated
<kiko> you should use maas/next
<ildar> I'm NOT joking, the serious page http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot says install maas/stable
<ildar> ;)
<kiko> ildar, if that is what you were using you'd be on 1.9.3
<kiko> ildar, so which is it?
<mpontillo> ildar: if you want to use autopilot you probably want the stable version of MAAS, which is still trusty-based
<mpontillo> ildar: so you want ppa:maas/stable on Ubuntu 14.04. sadly. =) everything should catch up soon...
<roaksoax> ildar: ppa:maas/stable is 1.9 series
<roaksoax> ildar: 2.0 series is ppa:maas/next
<roaksoax> and second what mpontillo is saying
<ildar> But that page doesn't explicitly says: Trusty
<kiko> it doesn't need to
<ildar> so I tried 1604
<kiko> I see the disconnect
<kiko> ildar, you deployed 16.04 which shipped with maas 2 beta2
<mpontillo> kiko: yeah that is an oversight, thanks for pointing that out ildar
<kiko> ildar, the stable PPA is not getting used because 1.9 is older than the version shipped in 16.04
<ildar> I see.
<kiko> ildar, so you either need to redeploy with 14.04 and use 1.9, or use the experimental PPA and move on to 2.0.
<kiko> ildar, if your objective is autopilot, then you want 1.9 and 14.04 everywhere.
<ildar> I tried MAAS on Trusty BTW
<ildar> MAAS worked finr
<ildar> MAAS worked fine
<kiko> sure it did! 1.9.3 is the bomb!
<ildar> but openstack installer failed to see the Ready nodes
<kiko> and if you had problems with autopilot then those are usually fixable :)
<ildar> complaining that no nodes available
<kiko> that's okay, we can probably get that fixed
<kiko> there are a bunch of little issues with the first part of openstack-install
<kiko> once landscape is running it's all good though
<ildar> OK
<kiko> anyway, ping us when you have 14.04 and 1.9.3 live
<ildar> then I'll get my 1404 MAAS and get back to
<ildar> that's a couple of minutes
<ildar> I saved it just in case ;)
<ildar> %&$*&*(&(*, my admin disabled internet access for the lab.
<ildar> Is MAAS able to work standalone, without internet?
<ildar> Commisioning seems stuck
<kmarsh> Hello...
<ildar> ahoy
<kmarsh> I'm trying to conjure-up openstack, and I think I have some maas erros that might be causing it to fail.
<ildar> what step is that?
<kmarsh> Is this the place to ask?
<ildar> sure! I'm doing the same here ;)
<kmarsh> I've been following Ubuntu's how-to, but with 16.04. http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot
<ildar> :P
<ildar> wrong
<ildar> just knew that
<kmarsh> I have a kind of working MAAS up using a 2interface controller and 4 nodes with 2 disks each.
<kmarsh> lol
<kmarsh> is there a better guide?
<ildar> oh! you get more then I
<ildar> no. Guys here say that you should use another ppa
<ildar> ppa:maas/next namely
<kmarsh> Yes, I had to use another ppa, hang on...
<kmarsh> add-apt-repository ppa:maas-maintainers/experimental3
<ildar> hah
<ildar> (2016-06-17 02:15:27) kiko: as 2.0 is not in that PPA
<ildar> (2016-06-17 02:15:56) kiko: you are using maas-maintainers/experimental
<ildar> (2016-06-17 02:16:00) kiko: which has been deprecated
<ildar> (2016-06-17 02:16:05) kiko: you should use maas/next
<ildar> is that that?
<kmarsh> OK I'll give that a try.
<ildar> I hope I gave the right advice
<ildar> as I just received that information
<ildar> and actually don't know much about MAAS
<kmarsh> thanks
<thetrav> so, the disk wipe feature seems to take an extremely long time.  What is the command MaaS actually executes here?
<thetrav> command / process / whatever
<mup> Bug #1593469 opened: [2.0] VMware power type error: __init__() takes 1 positional argument but 2 were given  <MAAS:New> <https://launchpad.net/bugs/1593469>
#maas 2016-06-17
<mup> Bug #1593487 opened: [2.0b7]maas-region-controller failed to preconfigure exit 127 <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1593487>
<axisys> how do I pick the network interface on virtualbox for maas? I was thinking eth0 as bridge and eth1 as host-only and enable maas-dhcp on eth1.. does it sound right?
<mpontillo> https://paste.ubuntu.com/17419813/ .. oh, thetrav left =(
<mup> Bug #1593516 opened: docs2.0/ha juju deploy maas-region not correct syntax <MAAS:New> <https://launchpad.net/bugs/1593516>
<ildar> hi again whoever unsleep
<ildar> http://paste.ubuntu.com/17425807/
<ildar> the problem is that after uninstallation error next installation stucks: it doesn't see "Ready" nodes and says "Not enough resources"
<romilos> hello
<romilos> I am trying to enlist a node but it stuck on login
<romilos> I use pxe boot and it is a VM
<romilos> and the node does not appears on maas interface
<romilos> yoooo
<ildar> did the node boot with PXE?
<romilos> y
<romilos> and then it stays in login
<ildar> login?
<romilos> it find maas and the os installed
<romilos> but then it stays at login
<ildar> the hostname ?
<romilos> it stays at ubuntu login:
<ildar> no
<ildar> it must have booted from the harddrive
<romilos> i think it did not
<romilos> it does not had any os pre-installed
<romilos> anyway I try again and I have disable the harddrive
<romilos> it happens the same again it stays at login
<D4RKS1D3> Hi
<kiko> hey D4RKS1D3
<mup> Bug #1593714 opened: [2.0, docs] DHCP start command documentation wrong for 2.0 <documentation> <MAAS:Confirmed> <https://launchpad.net/bugs/1593714>
<D4RKS1D3> Hi kiko
<mup> Bug #1593789 opened: [2.0RC1] Nodes API doesn't show regions <MAAS:New> <https://launchpad.net/bugs/1593789>
<mup> Bug #1593856 opened: Need a way to surface a name for an api-key in logs <oil> <MAAS:New> <https://launchpad.net/bugs/1593856>
<mup> Bug #1593881 opened: 2.0 beta7: Internal Server Error following installation <oil> <MAAS:New> <https://launchpad.net/bugs/1593881>
<mup> Bug #1593881 changed: 2.0 beta7: Internal Server Error following installation <oil> <MAAS:New> <https://launchpad.net/bugs/1593881>
<mup> Bug #1593881 opened: 2.0 beta7: Internal Server Error following installation <oil> <MAAS:New> <https://launchpad.net/bugs/1593881>
<mup> Bug #1593393 opened: MAAS fails to commission if requested immediately after boot images downloaded <MAAS:New> <https://launchpad.net/bugs/1593393>
#maas 2016-06-18
<mup> Bug #1593393 changed: MAAS fails to commission if requested immediately after boot images downloaded <MAAS:Invalid> <https://launchpad.net/bugs/1593393>
<mup> Bug #1571683 changed: Unable to Commission HP m800 cartridge with maas 1.9 and maas 2,0 <MAAS:Expired> <https://launchpad.net/bugs/1571683>
<mup> Bug #1593991 opened: 2.0 beta7: nodes enlisted manually through CLI added with a single power controller controlling all the nodes for power type IPMI <oil> <MAAS:New> <https://launchpad.net/bugs/1593991>
#maas 2016-06-19
<wililupy> Has anyone "successfully" gotten MAAS to connect to VMware ESXi6 using the VMware plugin? I keep getting certificate issues. I ended up purchasing a certificate from a trusted authority to install on the server, which I no longer get the Certificate error via the web browser connecting to the ESXi6 host, but even after adding the certificate to /etc/ssl/certs on the MAAS server, I still get the error that it can't verify the SSL
<wililupy> certificate in /var/log/maas/maas.log.
<mup> Bug #1594146 opened: Spurious failure in TestIPRangeSavePreventsOverlapping.test__dynamic_range_cannot_overlap_most_ip_types <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1594146>
#maas 2017-06-12
<cshen> Hi guys, we saw version 2.2 is released. but in our production system, we want to stick to 2.1 version. How can we still get 2.1 from PPA?
<mup> Bug #1695307 changed: Subnet details, static routes] The button name for bond says 'Edit' while it should say 'Edit static route' <ui> <MAAS:Fix Released by gbancroft-canonical> <https://launchpad.net/bugs/1695307>
<mup> Bug #1695307 opened: Subnet details, static routes] The button name for bond says 'Edit' while it should say 'Edit static route' <ui> <MAAS:Fix Released by gbancroft-canonical> <https://launchpad.net/bugs/1695307>
<mup> Bug #1695307 changed: Subnet details, static routes] The button name for bond says 'Edit' while it should say 'Edit static route' <ui> <MAAS:Fix Released by gbancroft-canonical> <https://launchpad.net/bugs/1695307>
<mohammed> atm_it
<vogelc> roaksoax: I am creating a local repo of the ubuntu images and boot loaders.  When I choose "connect" I keep getting 'no signature found'.  Thoughts??
<vogelc> roaksoax: I might have figured it out.  I removed the proxy info and it was able to connect.  I will send an update shortly
<vogelc> Does anyone know, if I created a local repo. During deploy it still saying downloading packages from archive.ubuntu.com.  Is it really pulling from the internet?
<vogelc> If so, how would I make the deployment pull from a local repo?
<vogelc> never mind.  I found the package repositories settings.  How ever it does not let me remove the default values an point to a local repository.  Any thoughts on how to do that?
<mup> Bug #1697541 opened: [2.2] Deployment fails if a cache set was created out of a partition of a device <MAAS:New> <https://launchpad.net/bugs/1697541>
#maas 2017-06-13
<mup> Bug #1697541 changed: [2.2] Deployment fails if a cache set was created out of a partition of a device <curtin:Incomplete> <MAAS:Invalid> <https://launchpad.net/bugs/1697541>
<vlad_> Hey everyone quick question or issue I wanted to discuss and see if there is an easy fix. I'm on MaaS 2.1.3 and I can't assign any networks on my 3rd fabric (fabric-2) to the second interface on a set of my nodes. Is this a UI bug / should I attempt to handle this from the CLI? Should I update?
<mpontillo> vlad_: you should be able to if you set the interface's vlan first; is there a problem with doing that?
<gnulnx> Could use a little help understanding the networking behind managing nodes.  PXE booting / enlisting a node obviously requires a NIC on the server to be set to boot from the network, but for things like BMC data, such as via IPMI, that is usually served from a separate NIC
<bdx> gnulnx: totally, so ensure you have that nic connected to the mgmt network
<gnulnx> I've yet to install a test system so I don't know what this looks like.  When adding a node, is there a place to configure both NICs?
<bdx> gnulnx: yeah ... the maas gui/cli should let you do all of that
<gnulnx> Thanks
<bdx> np
<gnulnx> IPMI NICs are usually (and in my case are) on a different network though.  How is that handled?
<gnulnx> The rackd servers would beed a NIC on both networks, right?
<bdx> gnulnx: right
#maas 2017-06-14
<kelvin> How does maas compare to openstack?
<cnf> are there any docs on upgrading from 2.1 to 2.2?
<cnf> also with juju, with maas 2.2, how can you filter on subnets now that spaces are vlan based, instead of subnet based?
<jam> cnf: probably better to ask here how they're hoping to model those cases
<cnf> hmm
<jam> cnf: I understand some of the rationale for it
<cnf> it breaks things, though, with no option that i can see
<jam> I believe the underpinning is "any machine on the same vlan can pretend to be on any subnet"
<jam> as nobody from the outside could tell that they shouldn't be there
<jam> and thus the same 'space'
<cnf> i find that to be very judgemental of other peoples networks
<jam> but I think there are (as you have) concrete realities around "yes, this port could be using 10.100, or 192.168, but I *want it to use 192* for these operations"
<cnf> especially "routed should be good enough"
<cnf> it isn't
<cnf> i have "this VLAN has NO routes, at all" vlans
<cnf> where you can add subnets
<cnf> but one subnet in it is not the other
<cnf> as there is no routing between them
<jam> cnf: so I thought vlan was supposed to be a "set of trunked switches", which if they are as you described, then they are separate vlans
<cnf> jam: that's a fabric
<cnf> from https://docs.ubuntu.com/maas/2.2/en/intro-concepts
<cnf> so now, from what I can see, i have no way in juju to define what _subnet_ i want
<cnf> at all
<cshen> cnf: we upgraded our existing maas installation from 2.1 to 2.2, so far no big issue. Only find one bug https://bugs.launchpad.net/maas/+bug/1695229
<jam> cnf: so if you can't model them as logically distinct VLANs (even if they had the same vlan-id they aren't logically the same space if they are swappable)
<jam> if they *aren't* swappable
<cnf> jam: so you are saying create a different fabric for each?
<cnf> but then i can't have 1 machine be in both at the same time
<cnf> because an interface can only be on 1 fabric
<cnf> and maas will not let you define the same vlanID twice on the same fabric
<cnf> work calls, i'll be back in a bet
<cnf> thanks for the help so far
<jam> mpontillo: ^^
<jam> I'd be happy to discuss through how we might model some of these issues
<cnf> ok, i'm back
<cnf> cshen: good to know, but i'm guessing you didn't use spaces a lot?
<cshen> cnf: what do you mean spaces?
<cshen> I use maas basically as a hardware provisioning tool for our prive openstack cloud.
<cshen> private openstack cloud
<cnf> cshen: do you not use segmented networks for your openstack install?
<cshen> you mean vlan?
<cshen> we really do vlan in networking.
<cshen> for instance, internal api, public api, storage, and so on.
<cnf> cshen: you don't use juju?
<cnf> or any automated way to get the machines from maas?
<cshen> no, we don't use juju.
<cshen> we write new machines into ansible inventory files.
<cnf> so if you want to tell maas "i want a machine, it needs to be in this subnet / vlan" you'd use spaces
<cnf> spaces where tied to subnets in 2.1
<cnf> and vlans in 2.2
<cshen> cnf: thanks for the ip.
<cshen> tip
<cnf> the transition is causing me problems
<cnf> i have VLAN's that contain multiple non-routed subnets
<cnf> and now i can no longer select which subnet needs to be used
<cshen> non-routed subnets, meaning no gateway?
<cnf> yep
<cnf> jam: btw, a related, but different problem i have is IP assignment to LXD containers in juju
<cshen> cnf: what do you mean "no longer select"? How do you "select"?
<jam> cshen: he used to be able to define 2 spaces that used the same vlan but had different subnets in them
<cnf> cshen: in juju, with constraints
<cnf> cshen: so i can say constraints: "spaces=admin-space,storage-space"
<cnf> for example
<cshen> cnf: oh, juju. I quit ;-)
<cnf> well, they are maas spaces, but yes, from juju
<cnf> jam: so i have subnets that really are _not_ under my control
<cnf> i need to ask for IP's to use in them, and request ACL's to be changed per ip
<cnf> i have no way to assign a specific IP to a specific container in juju, afaik
<cnf> (also, a lot of my constraints stem from "this part is not under my control)
<jam> after Juju has registered a device, can you assign it a concrete address?
<jam> it certainly is a case of "dynamic machine allocation" which doesn't play nicely with "static IP address allocation"
<cnf> jam: i don't know how to get juju to do that?
<cnf> especially with containers
<cnf> and yeah, i agree
<cnf> but that's my reality
<jam> cnf: when you juju deploy --to lxd:X we will eventually have created a device in MAAS
<jam> I don't know if you can go to MAAS UI and play around with the IP associated with that container
<cnf> no, once it's assigned, i can't
<cnf> i  can assign a static IP to a machine
<jam> cnf: do you have a pool that you could use, or is it "exactly this application has to use exactly that IP" ?
<cnf> before it gets provisioned
<cnf> jam: well, requesting "please open up all these ports for all ip's in this subnets" gets me a kind "why do you need all of those?"
<cnf> a reply of "my tool doesn't let me get selective on which ip i assign" of course gets replied to with "not our problem" :P
<cnf> i exaggerate, of course
<mup> Bug #1697931 opened: [2.2,snap] Proxy isn't running after installing the snap <snap> <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1697931>
<mup> Bug #1651165 changed: Unable to change disk name using maas gui <amd64> <apport-bug> <xenial> <MAAS:Triaged> <MAAS 2.2:New> <https://launchpad.net/bugs/1651165>
<mup> Bug #1697949 opened: MAAS renames VGname back to vg0 <MAAS:New> <https://launchpad.net/bugs/1697949>
<roaksoax> /3/win 16
<pmatulis>  /4\win56/tab4\paragraph5
<pmatulis> oops, sorry
<roaksoax> cnf: /win 4
<roaksoax> err
<mpontillo> jam: interface constraints in MAAS are powerful enough to match on more than just spaces; is there a way to pass a constraint through so cnf can do this without changing the definition of a space?
<mpontillo> jam: when the L3 -> L2 spaces issue was discussed, I remember thinking that we should have L2 spaces *and* L3 spaces so we could meet both of these use cases, but the team decided against that for simplicity sake IIRC
<mpontillo> I guess that's coming back to bite us
<mpontillo> on the other hand, the network setup here seems unusually difficult to model. cnf, if you can think of the simplest possible way to model your network in MAAS that would make things better for you, I'd like to hear it
<vlad_> Hey guys can maas provide dns/dhcp on an untagged lan or does it have to be vlans?
<BjornT> vlad_: untagged is fine
<vlad_> BjornT: Thanks man
<vlad_> Hey guys I just ran into an issue I have the controller connected to all the interfaces, but on one of them I have two non-tagged lans in as aliases. I can't seem to provide dhcp to all three of the subnets from the web-ui will I need to do something via the CLI to get this to work?
<cnf> mpontillo: sorry had meetings
<cnf> mpontillo: i'm tied with constraints from a network i consume, but don't maintain
<cnf> admitedly, i'm already jumping through hoops in maas to accomodate that
<vlad_> cnf: Yeah I'm in the same boat as you. I've got a network that's not ideal for this maas managed set of nodes I want to deploy openstack to
<cnf> yeah, doing openstack as well
<cnf> jam: so is there any way in juju to place constraints on subnets, instead of spaces?
<cnf> i see "networks" under legacy constraints...
<vlad_> cnf: Yeah most charms should have network definitions where you can specify lists of subnets
<cnf> vlad_: how?
<mpontillo> cnf: not sure how this is plumbed through to juju, but MAAS has an 'interfaces' constraint which is likely powerful enough to do what you need. it's like the legacy 'networks' constraint but lets you select individual interfaces instead of just on the whole box
<mpontillo> jam: ^?
<cnf> so my boxes only have 1 "interface" though
<cnf> a bond of 2 10G links
<cnf> everything else is vlans
<mpontillo> cnf: ah, then you can probably use either the 'subnets' constraint. the 'interfaces' constraint would work if you had multiple interfaces and you needed to know which one matched which constraint
<xygnal> hi guys.   I've noticed twice now that the MAAS API has been returning errors when using the API to provision a server,  even though all of the syntax for the command is correct.  Each time we've seen this, cycling maas-regiond is the only thing that fixed it.   How can I collect the proper debug information to file this as a bug?
<cnf> subnet constraint would work, but i don't think juju uses it?
<mpontillo> cnf: that is, in MAAS 2.x (I think -- maybe 1.9) the 'networks' constraint was replaced with the 'subnets' constraint.
<cnf> right
<mpontillo> cnf: right, that's why I was asking jam -- I don't know how/if it's exposed in juju. vlad_ seems to think it is ;-)
<cnf> well, i use subnets as constraints now, i just stick spaces to them :P
<cnf> right
<mpontillo> xygnal: I would take a look at /var/log/maas/regiond.log and check if there are any Python tracebacks
<mpontillo> xygnal: if you find one, file a bug and include it, please! (which version of MAAS?)
<mpontillo> xygnal: if you could pastebin it and send it to me here for a preview, I'll be able to confirm if it's enough to identify the issue
<mpontillo> xygnal: if it is, just hit https://bugs.launchpad.net/maas/+filebug and get it logged!
<xygnal> mpontillo yes, there are.  machine object is not iterable is the error, and there are indeed tracebacks.
<cnf> oh, i see all my maas bugs where closed
<xygnal> unfortunately we've seen this happen both when their synatx was right, and when their syntax was wrong, so I am going to have to sort out which tracebacks were when the syntax was right
<xygnal> mpontillo 2.2 release FYI
<xygnal> mpontillo 1697986
<mup> Bug #1697986 opened: API returns object is not iterable to valid API request for server deployment <MAAS:New> <https://launchpad.net/bugs/1697986>
<mpontillo> xygnal: thanks! if you could try the "Accept:" header workaround, and/or provide example API calls that cause this problem (or share some code) that would be very helpful
<mpontillo> xygnal: if it's the same as the "Accept" header issue, I'm not sure why restarting regiond would work around the problem
<xygnal> mpontillo do both of those workaround need to be in place at the same time?  the way it was phrased was either or.
<mpontillo> xygnal: it wouldn't hurt to make sure that accept header is always in place; if you do that you can remove the extra query string parameter for sure
<xygnal> mpontillo I tried the same request 4 times and got that error each time. THen I restarted maas-regiond, and my first repeat of the command worked.
<mpontillo> xygnal: but I'm going to mark that bug incomplete, since we'll need the API call (or CLI equivalent) before we can reproduce this
<mpontillo> xygnal: that's weird. if it's the "response is in a random format because it was unspecified" bug, I wouldn't expect it to be so consistent
<xygnal> honestly it appears to get 'worse' over time
<xygnal> until it reaches that point
<xygnal> the other day I was seeing it 'sometimes' but not every time
<xygnal> then today, ever time, until restart
<mpontillo> xygnal: hm. that's bizarre. maybe there is a backlog of API calls causing datatbase transactions to thrash, or something?
<xygnal> not sure.  I was thinking something along those lines.
<mpontillo> xygnal: do you think you could provide a sample MAAS CLI command that reproduces the error, or does it succeed with the MAAS CLI?
<xygnal> I have pgsql monitored in telegraf, any particular trashing you would expect to see?
<xygnal> we already restarted the service so it wont come back for a while
<mpontillo> xygnal: not really, I'm just throwing out theories =)
<mpontillo> xygnal: but if you see anything that piques your interest, it might be worth mentioning
<mpontillo> xygnal: but whatever insight you can give on that API calls you're making will be very helpful
<xygnal> I see 15 deadlocks in pgsql's statistics but those never go away even after restart
<xygnal> beyond that.. nothing stands out
<mpontillo> xygnal: we use postgres for locking so it makes me wonder if the deadlocks are intentional
<mpontillo> (though "deadlock", by definition, would indicate otherwise.)
<xygnal> yes, going back a month it was consistantly 14 deadlocks.  recently its up to 16.
<xygnal> does not flux
<xygnal> we are not mass building dozens of boxes at once, the load is almost always low
<mpontillo> xygnal: ok. are you able to add the "Accept" header? if so, I'm looking forward to hearing if that fixes that or not. (if not, I'd like to know which API call causes this and what parameters you're passing)
<xygnal> We will have to try it when we see this again.  Right now it is not a top priority, but i have notes for my team to try next time we see it.
#maas 2017-06-15
<MikeT> is anyone aware of being able to use SSO/LDAP for the MaaS web interface?
<tlian> QUESTION on maas cli: How to "Add alias or VLAN" to a bond interface?  It is simple using web interface. But having a hard time to do it via CLI
<tlian> @channel QUESTION on maas cli: How to "Add alias or VLAN" to a bond interface?  It is simple using web interface. But having a hard time to do it via CLI
<MikeT> @channel is anyone aware of a way to enable SSO/LDAP with the MaaS web interface?
<Test21> Heads up, you forgot a comma on the front page. (DevOps integration Integration with devops automation tools like conjure-up, Juju, Chef, Puppet, SALTAnsible and more).
<Test21> SATL, Ansible
<pmatulis> tlian, try 'maas $PROFILE interface update -h'
<pmatulis> (providing you're logged in as $PROFILE)
<pmatulis> Test2... thank you :)
<tlian> pmatulis, I did look into that... no success
<tlian> can you be more specific if you have run the command before to do the job ? thnx
<mup> Bug #1698181 opened: Switch to netplan renderer in Artful <cloud-images:New> <cloud-init (Ubuntu):New> <lxd (Ubuntu):Invalid> <maas (Ubuntu):New> <https://launchpad.net/bugs/1698181>
<pmatulis> tlian, please pastebin your exact command and its output
<tlian> maas cloginprofile interface update 'hneswp' 157 name="11.11.11.11-Prod" mac_address="xx:xx:xx:xx:xx:xx"
<tlian> that command do not update anything
<pmatulis> tlian, error output?
<tlian> I assume there should be parameter for the update
<tlian> this is from the HELP message
<tlian> Fields for bond interface:  :param name: Name of the interface. :param mac_address: MAC address of the interface. :param tags: Tags for the interface. :param vlan: Untagged VLAN the interface is connected to.  If not set     then the interface is considered disconnected. :param parents: Parent interfaces that make this bond.
<tlian> not sure how :param vlan is to be used
<tlian> is the parameter asking for the current vlan it is associated with ?   or Is it the new VLAN I want to add to the interface?
<pmatulis> tlian, the latter (new)
<pmatulis> tlian, the output doesn't say what is wrong with the command?
<tlian> pmatulis, just to be on the same page, you understand what I'm trying to accomplish - right?
<tlian> If not, I can re- explian :)
<pmatulis> tlian, you want to put a bonded interface in a VLAN?
<tlian> no
<tlian> I have a bonded interface which is run on "Untagged" VLAN as bond interface are only run on untagged vlan
<tlian> What I am trying to accomplish is to add additional VLAN to the bond interface
<tlian> from the Web UI, it will say "Add  alias or VLAN"
<pmatulis> right, that's what i meant
<tlian> Essentially, this is to make the interface associate with 2 VLAN... one being tagged and the other being a specific VLAN
<tlian> ok
<tlian> so the error is
<tlian> {"vlan": ["Select a valid choice. That choice is not one of the available choices."]}
<tlian> I verified the vlan does exist...
<pmatulis> ok, but i don't see "vlan" in your command above
<tlian> maas cloginprofile interface update 'hneswp' 157 name="11.11.11.11-Prod" mac_address="xx:xx:xx:xx:xx:xx" vlan="SQL"
<tlian> pmatulis, that's the full command
<tlian> Instead of specifying the vlan by name (vlan="SQL"), specifying it by id (vlan=8) generating a more useful error message
<tlian> {"vlan": ["A bond interface can only belong to an untagged VLAN."]}
<tlian> It looked like the above command move it to a different VLAN instead of adding an additional VLAN
<tlian> pmatulis, figured!  So, short answer is (1) First, create an interface of 'VLAN' type <interfaces create-vlan > (2) Secondly, link the interface to a subnet <interface link-subnet>
<pmatulis> tlian, sweet
<pmatulis> tlian, i recommend a follow up to the m/l post
<mup> Bug #1678339 opened: [2.2] Can't assign a static IP to a physical interface due to incorrect validation <MAAS:In Progress by mpontillo> <MAAS 2.2:In Progress by mpontillo> <https://launchpad.net/bugs/1678339>
<catbus> Hi, I have an SSD drive on a node, how come the 'create bcache' button is grey out on the node page?
<catbus> I figured other ways to create the bcache (via global settings and cli), but thought that button is the gui way of doing it on the per node basis.
<catbus> maas 2.2
<mup> Bug #1698240 opened: [MAAS 2.2.0] Creating tag definition with whitespace in XPath applies to all nodes <MAAS:New> <https://launchpad.net/bugs/1698240>
#maas 2017-06-16
<pmatulis> catbus, you need 2 drives
<catbus> pmatulis: 2 ssd drives? or just more than 1 block devices? All the nodes with nvme ssd have more than 2 block devices (sda, sdb).
<catbus> pmatulis: or do you mean I have to select 2 drives? I just tried selecting nvme ssd and sdb in the available disks and partitions, the create bcache button is still grey
<pmatulis> catbus, yeah, block device i'm pretty sure
<pmatulis> catbus, it's a 2-step process
<catbus> pmatulis: all nodes have more than 2. I am able to create bcache on these nodes via CLI on the node basis and global settings via web ui, but not web ui on the node page.
<catbus> sorry gotta go.
<boolman> Hey peeps, is it maas that's renaming all my interfaces at deploy? "mlx4_core 0000:82:00.0 enp130s0d1: renamed from eth3" I see theese entrys in the udev rules
<boolman> this is causing some problems for me, since I end up with interface names to long ( over 15 chars )
<roaksoax> boolman: you mean, it is renaming them on deploy ?
<roaksoax> boolman: maas <user> machine get-curtin-config <systemd_id>
<roaksoax> boolman: and see if maas is passing the right interface names
<roaksoax> boolman: if it is, and they are getting renamed
<cnf> morning
<vlado_> hello
<vlado_> i would like to add a windows image into maas server
<vlado_> how do i do it
<cnf> is it possible to create a soft raid mirror in maas, and boot the OS from it?
<boolman> roaksoax: It worked out when I added my custom boot params in settings
<boolman> roaksoax: net.ifnames=0 biosdevname=0
<cnf> boolman: \o :P
<cnf> boolman: you can also set them manually, btw
<cnf> in maas
<mup> Bug #1681771 changed: [UI, 2.2]Device discovery page has no maximum limit of devices shown <landscape> <performance> <MAAS:In Progress by ricgard> <https://launchpad.net/bugs/1681771>
<roaksoax> ///win 15
<cnf> :P
<mup> Bug #1698240 changed: [MAAS 2.2.0] Creating tag definition with whitespace in XPath applies to all nodes <MAAS:Invalid> <https://launchpad.net/bugs/1698240>
#maas 2018-06-11
<mup> Bug #1776137 opened: An error occurs when MAAS Commission under UEFI mode on ThinkSystem SR630 <MAAS:New> <https://launchpad.net/bugs/1776137>
<mup> Bug #1776137 changed: An error occurs when MAAS Commission under UEFI mode on ThinkSystem SR630 <MAAS:Invalid> <https://launchpad.net/bugs/1776137>
<mup> Bug #1763093 changed: Gateway can be choose in wrong subnet <MAAS:Expired> <https://launchpad.net/bugs/1763093>
<mup> Bug #1776137 opened: An error occurs when MAAS Commission under UEFI mode on ThinkSystem SR630 <MAAS:New> <https://launchpad.net/bugs/1776137>
#maas 2018-06-12
<studentz> For the command "sudo dpkg-reconfigure maas-region-controller" some tutorials  use the private interface and for the command "sudo dpkg-reconfigure    maas-rack-controller" they use the public interface. However, some tutorials  describe an opposite approach. Which is the correct one?. My understanding is  that the private interface is in charge of DHCP, PXE, IPMPI which are  functions of the rack-controller. Thanks
<candy`> morning
<candy`> do you know how I could restore default repo ? I try to add one through the cli and by mistake I overwrite the repo 1 (archive.ubuntu.com)
<candy`> I did try to restore the correct value, but I know have python error (PackageRepository.get_ports_archive().url), it say that url doesn't have attribute
<candy`> maas admin repo list look good (similar as the default one)
<enrico_> hello.. anyone has ever tried to build its own ISO source library? I would personalize my choises but no idea how to do build one? Please any tips? Thaaaaanks you !!!
<enrico_> ps. I already followed this guide but how to add private iso ?
<mup> Bug #1776526 opened: maas returning error 500 when querying raid by name not id <4010> <MAAS:New> <https://launchpad.net/bugs/1776526>
#maas 2018-06-13
<mup> Bug #1776604 opened: default DNS IP for node from unexpected interface (not always first interface or same network) <sts> <MAAS:Confirmed> <https://launchpad.net/bugs/1776604>
<tosaraja_> This might be a Ubuntu related question more, but just wondering if anyone has stumbled upon this kind of problem. We did a do-release-upgrade from 16.04 to 18.04 that upgraded MAAS. Now MAAS's web page doesn't open. netstat says that 5240 port is listened to, and I can open it with lynx locally and I receive MAAS's web page. But from outside it doesn't work. Firewall has been disabled as well. Anyone else had this when upgrading?
<BlackDex> is maas 2.4 going to be released to 16.04?
<mup> Bug #1776619 opened: Forms should use vanilla validation classes <ui> <MAAS:Triaged by deadlight> <https://launchpad.net/bugs/1776619>
<mup> Bug #1776741 opened: [2.4, UI] When a non-Ubuntu OS is selected as the default operating system OS, the action to 'deploy' doesn't provide kernel option when changing to Ubuntu <MAAS:Triaged> <MAAS 2.4:Triaged> <https://launchpad.net/bugs/1776741>
#maas 2018-06-14
<elox> Hello. Is there a good guide as how to manually install a  juju-controller for a maas cloud without having to perform a "juju bootstrap" process from the API. E.g. I have a node already installed and just want to connect it to a maas.
<zin> hello
<CR> howdy, I am starting up trying to use MAAS and I have a node that has trunked ports connected to it, I am able to get it to PXE boot by setting the VLAN in the NIC's PXE options and starts loading the OS but it does not get a DHCP address in the OS.  I have the VLAN ID in the VLAN config in MAAS and also tried just passing vlan=vlan830 in the kernel boot options.
<CR> Am I missing something?
<roaksoax> CR: pxe boot process doens't use tagged interfaces
<roaksoax> CR: so if your PXE is happening on a VLAN, there should be switch port configured with that vlan so the interface doens't have to be tagged (e.g. eth0.830)
<roaksoax> CR: dunno if that's what you were asking
<CR> so it gets the PXE image, it's getting that far and gets the initrd images, it's once it hits hte "IP-Config" part
<roaksoax> right, so the image itself doens't get dhcp ?
<roaksoax> CR: maybe the hardware you are using is a hardware for which the drivers are not available
<CR> It's a Dell R910 w/ Broadcom NICs
<CR> roaksoax: I see IP-Config: eno1 hardware address 78:2b:cb:xx:xx:xx mtu 1500 DHCP RARP
<CR> and then times out
<roaksoax> CR: i would suggest you grub console logs
<roaksoax> s/grub/grab
<CR> roaksoax: is that an option in maas or somewhere else?
<roaksoax> CR: no, i mean the console logs from the server's serial console
<CR> roaksoax: it appears I need to do something similar to the fix described in here: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1382054  Is there a way to pass a VLAN to the initramfs with the standard MaaS setup?
<roaksoax> CR: that is a feature request in the initrd it seems
<CR> roaksoax: it would be very useful, our use case is we have a bunch of former VMware ESXi we would like to try out MaaS on and their ports are all configured as trunk ports and it would be a lot easier to boot them and pass the VLAN tag to them then have to get our network team to reconfigure the switchports just to do a POC.
<roaksoax> cnf: agreed, but that seems that something ubuntu would have to support more generally
<cnf> hmm?
<roaksoax> cnf: so, how does the "firmware" deal with the fact you are pxe booting over a VLAN ?
<cnf> idno
<roaksoax> err cnf sorry, wrong person :)
 * roaksoax fail
<cnf> :P
#maas 2018-06-15
<mup> Bug #1777019 opened: nginx config does not handle IPv6 addresses <MAAS:Confirmed> <https://launchpad.net/bugs/1777019>
<mup> Bug #1777111 opened: Upgrade from 2.3.3 to 2.4.0 fails with inability to connect to postgres <MAAS:New> <https://launchpad.net/bugs/1777111>
<mup> Bug #1777131 opened: Wrong RAM size shown for server <cpe-onsite> <MAAS:Incomplete> <https://launchpad.net/bugs/1777131>
<mup> Bug #1777131 changed: Wrong RAM size shown for server <cpe-onsite> <MAAS:Invalid> <lshw (Ubuntu):Confirmed> <https://launchpad.net/bugs/1777131>
<mup> Bug #1777131 opened: Wrong RAM size shown for server <cpe-onsite> <MAAS:Invalid> <lshw (Ubuntu):Confirmed> <https://launchpad.net/bugs/1777131>
<mup> Bug #1777131 changed: Wrong RAM size shown for server <cpe-onsite> <MAAS:Invalid> <lshw (Ubuntu):Confirmed> <https://launchpad.net/bugs/1777131>
<mup> Bug #1777169 opened: Network discovery page tracks stale devices <MAAS:New> <https://launchpad.net/bugs/1777169>
#maas 2020-06-08
<ritzttk> Hi, I'm deploying Openstack charm bundle by Juju + Maas, and it stucked on "allocating unit". This is output of juju status : https://paste.ubuntu.com/p/6cc5mzFMj9/ . Please have a look and help me troubleshoot this case. Sorry for bothering you
<ritzttk> This is log on server number 2 https://paste.ubuntu.com/p/2bDGxk7q4w/. It look like server shutdown all services because ntp timed out. It's connecting on a vlan interface
<ritzttk> this is my space information : https://paste.ubuntu.com/p/TzgRDGf4MN/
<mup> Bug #1882371 changed: [2.8/candidate] /snap/maas/current/helpers/maas-database-setup missing <MAAS:Invalid> <https://launchpad.net/bugs/1882371>
<mup> Bug #1882371 opened: [2.8/candidate] /snap/maas/current/helpers/maas-database-setup missing <MAAS:Invalid> <https://launchpad.net/bugs/1882371>
<mup> Bug #1882371 changed: [2.8/candidate] /snap/maas/current/helpers/maas-database-setup missing <MAAS:Invalid> <https://launchpad.net/bugs/1882371>
<mup> Bug #1880755 changed: snap upgrade requires 2x disk space <MAAS:Fix Released by ack> <https://launchpad.net/bugs/1880755>
<mup> Bug #1881361 changed: Websocket doesn't show interface test failure when one iface passes and another fails <MAAS:Fix Released by ltrager> <MAAS 2.7:In Progress by ltrager> <https://launchpad.net/bugs/1881361>
<mup> Bug #1801420 opened: Deployment fails if install_kvm=true and user_data blob is passed <cpe-onsite> <MAAS:Confirmed> <https://launchpad.net/bugs/1801420>
<ticapix> Hello
<ticapix> while following the tutorial https://maas.io/install, when I run maas init, I'm asked a db host, username and so on
<ticapix> What is it about ?
<ticapix> what type of DB shoult I setup on the side ?
#maas 2020-06-09
<mup> Bug #1882633 opened: Logical volume size is required <MAAS:New> <https://launchpad.net/bugs/1882633>
<mup> Bug #1882633 changed: Logical volume size is required <MAAS:New> <https://launchpad.net/bugs/1882633>
<mup> Bug #1882633 opened: Logical volume size is required <MAAS:New> <https://launchpad.net/bugs/1882633>
<mup> Bug #1882798 opened: Can't deploy CentOS 6 with xfs filesystem <MAAS:New> <https://launchpad.net/bugs/1882798>
<mup> Bug #1882798 changed: Can't deploy CentOS 6 with xfs filesystem <MAAS:New> <https://launchpad.net/bugs/1882798>
<mup> Bug #1882798 opened: Can't deploy CentOS 6 with xfs filesystem <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1882798>
<mup> Bug #1882798 changed: Can't deploy CentOS 6 with xfs filesystem <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1882798>
<mup> Bug #1882798 opened: Can't deploy CentOS 6 with xfs filesystem <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1882798>
<mup> Bug #1882806 opened: Broken test in test_maas_certificates <MAAS:Triaged by d0ugal> <https://launchpad.net/bugs/1882806>
<mup> Bug #1882809 opened: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 changed: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 opened: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 changed: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 opened: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 changed: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
<mup> Bug #1882809 opened: available_size for md devices is higher than space available resulting in failures <MAAS:New> <https://launchpad.net/bugs/1882809>
#maas 2020-06-10
<mup> Bug #1882145 changed: MAAS 2.8 snap test-db install fails when running as (default) root in a container <MAAS:Fix Released by bjornt> <https://launchpad.net/bugs/1882145>
<mup> Bug #1882145 opened: MAAS 2.8 snap test-db install fails when running as (default) root in a container <MAAS:Fix Released by bjornt> <https://launchpad.net/bugs/1882145>
<mup> Bug #1882145 changed: MAAS 2.8 snap test-db install fails when running as (default) root in a container <MAAS:Fix Released by bjornt> <https://launchpad.net/bugs/1882145>
<mup> Bug #1882903 opened: Failing test in provisioningserver.tests.test_config <MAAS:Confirmed> <https://launchpad.net/bugs/1882903>
<mup> Bug #1882911 opened: Failure to update pod with error cascade attempting to talk to virsh <MAAS:New> <https://launchpad.net/bugs/1882911>
<mup> Bug #1882911 changed: Failure to update pod with error cascade attempting to talk to virsh <MAAS:New> <https://launchpad.net/bugs/1882911>
<mup> Bug #1882911 opened: Failure to update pod with error cascade attempting to talk to virsh <MAAS:New> <https://launchpad.net/bugs/1882911>
<mup> Bug #1882964 opened: deployment HANGS on removing pre-existing devices <MAAS:New> <https://launchpad.net/bugs/1882964>
<wahnsinn233> Hey guys, I have installed MAAS 2.8 on Ubuntun using Snap and try to configure it with an external dhcp server. The DHCP server sends the correct PXE IP, I can see the tftp traffic on the interface but the machine I'm trying to add has a timeout when using tftp
<wahnsinn233> Currently I'm using  "/var/lib/tftpboot/pxelinux.0" as PXE path - is that correct? Unfortunately I can't find anything in the docs
<wahnsinn233> I tried following what this guy did on MAAS 2.4.2: https://www.portegi.es/blog/maas-1 , but the /var/lib/dhcpd.conf is not created, even when I enable DHCP
<wahnsinn233> Can anyone help?
<mup> Bug #1882974 opened: [web UI] Action status doesn't update, page reload required <MAAS:New> <https://launchpad.net/bugs/1882974>
<mup> Bug #1882974 changed: [web UI] Action status doesn't update, page reload required <MAAS:New> <https://launchpad.net/bugs/1882974>
<mup> Bug #1882974 opened: [web UI] Action status doesn't update, page reload required <MAAS:New> <https://launchpad.net/bugs/1882974>
<mup> Bug #1882979 opened: Slow formatting on SSDs in mdadm RAID10  with LVM and XFS <MAAS:New> <https://launchpad.net/bugs/1882979>
<adell> hello
<adell> exists a channel in portuguese?
<mup> Bug #1882985 opened: Need a way to list available maas config options from CLI <MAAS:New> <https://launchpad.net/bugs/1882985>
<mup> Bug #1882985 changed: Need a way to list available maas config options from CLI <MAAS:New> <https://launchpad.net/bugs/1882985>
#maas 2020-06-11
<mup> Bug #1883053 opened: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:New> <https://launchpad.net/bugs/1883053>
<mup> Bug #1883053 changed: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:New> <https://launchpad.net/bugs/1883053>
<mup> Bug #1883053 opened: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:New> <https://launchpad.net/bugs/1883053>
<mup> Bug # changed: 1878643, 1881275, 1881664, 1881804, 1882313
<mup> Bug #1883053 changed: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:Invalid> <https://launchpad.net/bugs/1883053>
<mup> Bug #1883053 opened: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:Invalid> <https://launchpad.net/bugs/1883053>
<mup> Bug #1883053 changed: Maas 2.8.0- rc2 :  Download  Focal 20.04  not possible. <MAAS:Invalid> <https://launchpad.net/bugs/1883053>
<mup> Bug #1883132 opened: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1883132>
#maas 2020-06-12
<mup> Bug #1883132 changed: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:Fix Released by huwshimi> <maas-ui:New> <https://launchpad.net/bugs/1883132>
<mup> Bug #1883132 opened: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:Fix Released by huwshimi> <maas-ui:New> <https://launchpad.net/bugs/1883132>
<mup> Bug #1883132 changed: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:Fix Released by huwshimi> <maas-ui:New> <https://launchpad.net/bugs/1883132>
<mup> Bug #1883132 opened: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:Fix Released by huwshimi> <maas-ui:New> <https://launchpad.net/bugs/1883132>
<mup> Bug #1883132 changed: CSS misstyled when accessing angular pages from redirect <ui> <MAAS:Fix Released by huwshimi> <maas-ui:New> <https://launchpad.net/bugs/1883132>
<mup> Bug #1883232 opened: UI application cached after upgrade <ui> <MAAS:New> <https://launchpad.net/bugs/1883232>
<mup> Bug #1883232 changed: UI application cached after upgrade <ui> <MAAS:New> <https://launchpad.net/bugs/1883232>
<mup> Bug #1883232 opened: UI application cached after upgrade <ui> <MAAS:New> <https://launchpad.net/bugs/1883232>
<mup> Bug #1883269 opened: UI traceback adding alias to nic <ui> <MAAS:In Progress> <maas-ui:Unknown> <https://launchpad.net/bugs/1883269>
<mup> Bug #1883269 changed: UI traceback adding alias to nic <ui> <MAAS:In Progress> <maas-ui:Unknown> <https://launchpad.net/bugs/1883269>
<mup> Bug #1883269 opened: UI traceback adding alias to nic <ui> <MAAS:In Progress> <maas-ui:Unknown> <https://launchpad.net/bugs/1883269>
<mup> Bug #1883294 opened: maas changepassword does not have automatable options <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1883294>
#maas 2020-06-13
<mup> Bug #1883333 opened: Allow for_hardware scripts to use any system information collected during commissioning. <MAAS:In Progress> <https://launchpad.net/bugs/1883333>
<mup> Bug #1883333 changed: Allow for_hardware scripts to use any system information collected during commissioning. <MAAS:In Progress> <https://launchpad.net/bugs/1883333>
<mup> Bug #1883333 opened: Allow for_hardware scripts to use any system information collected during commissioning. <MAAS:In Progress> <https://launchpad.net/bugs/1883333>
<mup> Bug #1883337 opened: UI should show all system information fields <ui> <MAAS:New> <https://launchpad.net/bugs/1883337>
<mup> Bug #1883349 opened: [2.7.1] Pod VMs lose static IP after powering down <MAAS:New> <https://launchpad.net/bugs/1883349>
