#maas 2012-09-10
<Daviey> jtv: hey, what is omshell?
<jtv> Hi
<jtv> It's a way of talking to dhcpd.
<jtv> You can run it as an interactive shell to issue commands like "create a new host mapping."
<jtv> (Which is the kind of thing we use if for, in fact)
<Daviey> yeah, i should have just read the docstring :)
<Daviey> sorry
<Daviey> i was sort of hoping it was related to the cmd line interface :DDD
<bigjools> Daviey: wtf are you doing up
<Daviey> bigjools: nothing like doing code reviews in the middle of the night eh?
<bigjools> Daviey: fun
<lifeless> bigjools: do we need to talk today?
<bigjools> lifeless: possibly - can we do it in 1.5h or so?
<lifeless> anytime
<bigjools> thanks
<bigjools> assuming my 12.10 upgrade doesn't completely hose this machine
<roaksoax> mornin
<roaksoax> rvba: howdy!
<rvba> roaksoax: hello
<roaksoax> rvba: how's it going
<roaksoax> rvba: so, i tested the stuff for the release thing
<roaksoax> rvba: and it ended up not having anything
<rvba> What do you mean?
<roaksoax> rvba: on the database, as in, the database didn
<roaksoax> rvba: on the database, as in, the database didn't store the default release
<rvba> Well, did you create a default for the config value?
<rvba> But the db will store the default only if it's changed.
<roaksoax> rvba: right, but doesn't that mean, if for example, the CharField model params are, Choices and defaul
<rvba> The default should be defined in src/maasserver/models/config.py:get_default_config
<rvba> Ah, *that* default..
<rvba> Do you have a branch I could have a look at?
<roaksoax> rvba: sure, http://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/976
<roaksoax> rvba: that;s what I did at first
<roaksoax> now I'm gonna test this:
<roaksoax> http://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/978
<rvba> roaksoax: I thought we wanted a None default.  So that one could be able to change the default release used globally.
<rvba> ?
<roaksoax> rvba: we don't want None as deafult, we want a particular release as default
<roaksoax> rvba: so basically s/UBUNTU_RELEASE.precise/UBUNTU_RELEASE.default
<rvba> Sure, but in the db, this will mean that the value of os_release will be None when this should be left to the global default.
<roaksoax> rvba: right, so lets imagine precise is the default, how to make sure it gets stored in the DB?
<roaksoax> becuase the documentation tells me that choices=XYZ default=XYZ.one
<roaksoax> stores XYZ.one if none has being given
<roaksoax> right?
<rvba> What you propose will mean that the default is something decided by the value of UBUNTU_RELEASE.default.  My idea was that the default should be something that a user could change.
<rvba> But I guess we can iterate on that.
<roaksoax> rvba: right, UBUNTU_RELEASE.default will be ultimately be chosen by the user, but we still need a default regardless of the fact that the user can chose it
<roaksoax> rvba: we cannot go without release if the user does not choose a default
<rvba> roaksoax: hence the default value in src/maasserver/models/config.py:get_default_config
<roaksoax> so UBUNTU_RELEASE.default can be obtained from a config, but if it is not given it should default to the stable release
<rvba> roaksoax: so, the default=â¦ is used when a new object is created.
<roaksoax> rvba: =right, so when enlisted, the machine should end up with os_release=Precise (the default)
<roaksoax> rvba: so this is what happens, with the branch above, we enlist a machine
<roaksoax> the machine enlists successfully
<rvba> roaksoax: I thought the os_release field should contain the name of the release used for the next install.  Not the current release.
<rvba> Maybe I misunderstood what you were trying to do.
<roaksoax> rvba: os_release should contain the release it will use for the install, but if none is given it should default. In this case, it defaults to precise
<roaksoax> rvba: that's the only stable release at the moment
<rvba> Ok, so I got it right.
<roaksoax> rvba: for enlistment/commissioning, there's no ephemeral images other than precise
<roaksoax> rvba: so this is the problem with the above branch
<roaksoax> rvba: 1. the machine enlists. 2. machine gets stored in DB *with* os_release *None*. 3. On commissioning, it fails for not having set release
<rvba> roaksoax: do you have a failing test that could illustrate what the problem is?
<roaksoax> rvba: a software test, no not really. Basically the problme is that with the branch above the os_release value in the DB is None instead of the default (precise)
<rvba> roaksoax: ok, I understand.  Let me see what I can do.
<roaksoax> rvba: because as far as I understand, the DB should have stored the default value if it has not been specied due to the fact that if no value is specified, then "we store the defualt"
<roaksoax> rvba: the other thing would be in the API verify that if no release has been sent during enlistment, set the value?
<rvba> roaksoax: indeed, there is something wrong here.  But like I said, I think we should keep the behaviour of storing None if no specific release has been set, and then not use node.os_release directly but a small method get_os_release.
<rvba> That method will use the default if the value of node.os_release is None.
<rvba> What's the benefit from doing this over storing the default directly you might askâ¦
<rvba> Well, if will let use have a globally defined default under the control of the user.
<roaksoax> rvba: could you exemplify
<rvba> roaksoax: sure:
<rvba> Say you have 100 nodes.
<rvba> None of which need a specific release so you decide to go with the default.
<rvba> Then, later, a new release comes out an you want your node to use that release.
<rvba> If, during the first registration of the node, each of them had the release stored onto them, you'll need to change each and everyone of them to 'upgrade' to a new release.
<rvba> If, instead, node.get_os_release() does something like:
<rvba> If node.os_release is None:
<rvba>     return globally_configured_release
<rvba> else:
<rvba>     return node.os_release
<rvba> Then all you need to do is change the global setting 'globally_configured_release'.
<rvba> Does that make sense?
<roaksoax> rvba: right
<roaksoax> rvba: so, that would actually be needed on the preseed side of things and nothing to be changed on the forms and model
<rvba> roaksoax: that would look like this: http://paste.ubuntu.com/1196615/
<rvba> roaksoax: err http://paste.ubuntu.com/1196620/
<roaksoax> rvba: is the print(UBUNTU_RELEASE_CHOICES) necessary?
<rvba> roaksoax: no, that was for my own benefit :)
<roaksoax> rvba: hehe ok cool
<roaksoax> rvba: I'll give it a test
<roaksoax> thanks for the input and patch
<rvba> np
<rvba> roaksoax: the default is taken into account correctly btw, http://paste.ubuntu.com/1196624/
<rvba> roaksoax: also, I understand you're not there yet but please put the code used to initialize the release names into methods.  This way it will be much more easy to test.
<roaksoax> rvba: alright
<roaksoax> rvba: i'll run it with you before proposing it, either way, there's gonna be lots of tests that will need to get fixed
<rvba> roaksoax: right.
<rvba> roaksoax: I'll give you a hand (with tests and stuff) when you'll be satisfied with the behaviour.
<mgz> the lshw json output is rather verbose... <http://pastebin.ubuntu.com/1196630/>
<roaksoax> rvba: cool thanks
<roaksoax> rvba: thoughts? http://paste.ubuntu.com/1196743/
<rvba> roaksoax: in api.py, line 1144 and above, I see that node is set to None if macaddress is Noneâ¦
<roaksoax> rvba: yeah just figured it too :)
<rvba> roaksoax: looks like you need to provide a default for the os_release in that case as it cannot be derived from the node.
 * roaksoax going blind
<roaksoax> rvba: i think it doesn't really make sense to show "Default Release" on the WebUI
<roaksoax> so I'll remove that
<rvba> roaksoax: what do you want to put instead?
<roaksoax> rvba: nothing
<rvba> roaksoax: as inâ¦ the empty string?
<rvba> Or you want to drop that option completelyâ¦?
<roaksoax> rvba: no, just from the UI
<roaksoax> rvba: from the combobox
<roaksoax> rvba: it will remain a UBUNTU_RELEASE.default but will not be in UBUNTU_RELEASE_CHOICES
<rvba> roaksoax: I don't really understandâ¦ we want the user be able to say that the node should use the globally configured release don't you think?
<roaksoax> rvba: yeah, it does use that
<roaksoax> rvba: it is just not a choice on the WebUI
<roaksoax> rvba: remove this:
<roaksoax> +    else:
<roaksoax> +        UBUNTU_RELEASE_CHOICES += ((UBUNTU_RELEASE.default, 'Default release'),)
<rvba> roaksoax: so a user won't be able to say that a node should use the globally defined default.
<rvba> He will be forced to specify a particular release.
<roaksoax> rvba: nope
<roaksoax> rvba: there will always be a default
<rvba> This sort of makes the whole idea of having a globally configurable default pointless.
<roaksoax> rvba: it doesn
<roaksoax> rvba: using a globally configured one differs from what the WebUI displays
<roaksoax> rvba: UBUNTU_RELEASE_CHOICES is only to list what choices are on the WEbUI
<roaksoax> rvba: but the default will always be one of the CHOICES
<roaksoax> rvba: so UBUNTU_RELEASE.precise, UBUNTU_RELEASE.quantal, UBUNTU_RELEASE.defaul, but the WebUI will only display "(precise,Uuntu Preicse), (quantal,Ubuntu Quantal)"
<rvba> I understand the consequences :)
<rvba> But I don't understand the motivation behind that change tbh.
<roaksoax> rvba: so in this case, .default = precise, so when it comes to the choice, it will chose .precise
<roaksoax> rvba: the reason to the change is that the release should be selected by default, but that, instead of showing "Default Release", it should show the actual default that has been selected
<rvba> If your concern is that "Default release" is not explicit enough we can fix that properly.
<roaksoax> rvba: no it is not about being explicit, it is just simply what you present to the user
<rvba> Because the value 'Default release' is different from 'precise' or 'quantal'
<roaksoax> rvba: there's no need to present "Default Release" when you already know that the default relase is either "Ubuntu PRecise" or "Ubuntu Quantal"
<rvba> It might mean that it will use 'precise' for now, but later it might be another release if you change the global default.
<roaksoax> rvba: exaclt, so if you change the fglobal default, in the WebUI should show the selected default
<rvba> roaksoax: yes, there is a need, because using the global default has another meaning than just 'precise'
<roaksoax> rvba: exactly, but globally defined means that it will be *one* of the choices
<roaksoax> rvba: we should present "default" as a choice, because "default" *is* a choice
<rvba> Using the global default which happens to be precise right now means something else than forcing that node to use precise.
<rvba> roaksoax: you lost me now.  I'm arguing to keep 'default' as a choice :) among the explicit names of the releases.
<roaksoax> rvba: exaclty, I understand, but we should not *present* in the  WebUI a value "Default Release" when we can simply present *the* selected default release
<rvba> roaksoax: that won't work, let me give you an example:
<roaksoax> rvba: ok so WebUI will show "1. Ubuntu Precise", "2. Ubuntu Quantal", so you set the config option to be "quantal", so that becomes default right?
<roaksoax> rvba: so when you enlist a node, the WebUI value sould be "2. Ubuntu Quantal"
<rvba> roaksoax: we're talking about the a value that can be modified by the user in the "edit a node" page.
<roaksoax> but if you change the default in the config, let's say you add lucid to the choices, on enlistment,  "3. Ubuntu Lucid" should be selected
<roaksoax> instead of "Default release"
<roaksoax> rvba: yes
<roaksoax> rvba: we don't need to be able to save a "default" release
<roaksoax> rvba: the user should chose a release if he wants to *chage* from the default
<rvba> so: yes we do: let me give you an example.
<rvba> roaksoax: a user edits a node: the default is selected (precise), he changes that to quantal.
<rvba> roaksoax: then he changes his mind and he wants to set it to the default again.
<rvba> roaksoax: he clicks on 'precise' but will this see it back to using the default or will this force precise on this node?
<rvba> s/see/set/
<roaksoax> rvba: ahhh I see your point now
<roaksoax> rvba: ok but, are we expecting to have commissioning images from every supported release or only for 1 release
<roaksoax> smoser: are we expecting to have commissioning images of every release?
<roaksoax> smoser: every release we support in MAAS?
<roaksoax> rvba: but now, if we want that, we would need to add a default release option under Settings on the WebUI
<rvba> roaksoax: that's exactly why we have the default stored a Config object.
<roaksoax> rvba: because yes, if we have default, moved to quantal, and then I decide to move back to the default, then I'd need to select the particular release
<rvba> roaksoax: a one-line modification to the forms used in the Settings page will get us sorted.
<roaksoax> rvba: yes I see your point, and I think it is a fair option. '
<rvba> roaksoax: cool
<smoser> rvba, right now i think i'm leaning towards having commissioning images of each release. but probably defaulting in maas to a.) only import '$(ubuntu-distro-info --lts)'
<smoser> hm..
<smoser> just a
<smoser> i forgot what b was.
<roaksoax> rvba: the other is that default should be distro-info --supported
<roaksoax> err /s/supported/stable
<rvba> roaksoax: then we simply need to build the choices for the config option (on the Settings page) with only the stable releases.
<roaksoax> smoser: what's the differece between ubuntu-distro-info and distro-info
<smoser> nothing on ubuntu
<smoser> on debian distro-info == debian-distro-info
<roaksoax> smoser: ok cool
<smoser> and here, i think we specifically are asking an ubuntu question
<smoser> (and --lts is bad usage for debian-distro-info)
<smoser> rvba, roaksoax so you were discussing up above selection of the to-be-installed OS ?
<rvba> smoser: yes
<smoser> i'd suggest that '--lts' is probably the right default for that also. and let it be user-modifiable.
<smoser> but i consider it a requirement that this is an input to the api for deployment.
<rvba> Once os_release will be added to the node object, one will be able to use the API to modify that value for each node.
<smoser> i don tthink thats the right way.
<smoser> just because i want "quantal" for this installation does not mean I am changing that nodes "default"
<smoser> that should not be sticky in any way
<smoser> (ie, i think you're suggesting that my client would then have to change the nodes data, and then request deploy)
<rvba> I see, you'd like pre-deployement setting.
<smoser> i want to say "give me a node with 12.10"
<smoser> i dont even want to know what node that is.
<roaksoax> smoser: but that assumes that we would randomly chose a node and install 12.04 on it
<rvba> roaksoax: that's pretty different from storing the release used by the node on the node itselfâ¦
<rvba> roaksoax: what smoser said I mean.
<roaksoax> yah
<smoser> i suggest that htere is a list of "supported OS releases to install"
<smoser> and possibly a "default if unspecified"
<roaksoax> smoser: yes but for each node, you should need to be able to chose a release you want for it
<smoser> i dont see much use case for "default for a node"
<smoser> as that is only making it hard to use.
<roaksoax> smoser: you should not just randomly "get a node with 12.10"
<roaksoax> smoser: that would be juju's job IMHO
<roaksoax> rvba: inventory will be within maas right?
<rvba> roaksoax: as in hardware inventory?  Yes.
<smoser> i relaly think you want to invision this like a VM.
<smoser> anyway..
<roaksoax> smoser: right, but that's not the piurpose of inventory
<roaksoax> smoser: i don't say we can't do that, but I'm just saying we should still have the ability to choose what node should have what release
<smoser> it seems wrong for me to have to modify an attribute of a node to "deploy with 12.10"
<smoser> roaksoax, i really dont care about that.
<smoser> i honestly cannot see any reason that anyone ever would say "give me a node" without a care as to what OS was on it.
<smoser> (which you'd essentially be doing if you relied on the 'default')
<roaksoax> smoser: right, but that's why you have juju for
<roaksoax> smoser: becuase if inventory is done within maas, you can treat a machine like a VM in that particular aspect
<smoser> well thats fine. so juju specified the release then.
<smoser> but from the api perspecitve "give me a node" takes a release.
<smoser> having a default is fine
<smoser> but really, thats only going to piss people off
<smoser> when one day the default changes
<smoser> and all their stuff breaks
<smoser> so anyone intelligent is going to specify it
<smoser> that make sense?
<roaksoax> smoser: right, but do you really think an admin wil simply say "give me *a* node, whatever it is and install precise on it?"
<smoser> yes.
<roaksoax> smoser: or will they say "I want to deploy *this* node, that has precise on it"
<smoser> if i have 4000 nodes and they're all the same.
<smoser> i do not want to chose one
<rvba> smoser is right.
<smoser> or look at a list of what is available
<rvba> In the context of having tons of node, deploying to individual nodes is not the priority.
<rvba> And probably what we should optimize for, even if that should be possible.
<roaksoax> it is not, but that doens't change the fact that you know, before hand, what release should a node have
<roaksoax> again I'm not saying smoser's suggestion can't be done
<roaksoax> i'm simply saying, we should  think where that lies, if it should lie within juju
<roaksoax> or within maas
<rvba> But maybe a global default is all we need.
<roaksoax> rvba: right, IMHO, we should keep things the way they are, and add smosers suggetions to the question
<rvba> And one could override that default when deploying a node.
<roaksoax> rvba: right, but we should still be able to have inventory on that, don't we?
<smoser> heres why global default doesn't really work: 10.04 wont install on system X because system X has sandybridge. so having a global default of 10.04 clearly cannot work.
<roaksoax> rvba: that means that after installation, the DB should be updated with the current release of the installed system
<smoser> but the user wants 10.04 "by default" except for that node (or class of nodes)
<smoser> but this really doesnt matter to me.
<smoser> and just leads to some more complex "list of supported OSes on this node"
<rvba> roaksoax: what's the link between this and the harware inventory?
<rvba> hardware*
<smoser> so my feeling right now is a global default, but i would suggest that it is a best practice to always specify it in the api when you request a node.
<smoser> which basically makes the 'global default' a "bad practice" :)
<smoser> in short, i suggest using global default for now. realizing that it is insufficient when a given set of hardware cannot be supported by a release.
<smoser> and we have that to figure out somepoint in the future or just live with.
<smoser> hardware invententory and "supported hardware db" and things of that sort could make selection magical and know that information outside of maas
<roaksoax> rvba: hardware inventory means that you will know "these set of nodes will have precise" "these set of nodes will have quantal"
<smoser> "will have" ?
<smoser> "support" ?
<roaksoax> smoser: so you suggest not being able to chose a particular release for a particular node, or set of nodes and pre-define that?
<roaksoax> smoser: support is pre deployment, will have is for-deployment/post-deployment
<smoser> roaksoax, i suggest that it is a requirement to be able to specify a release at deploy time.
<smoser> i dont know what "chose" means other than that.
<smoser> and whoever is requesting a node to be deployed is going to want to specify what release they want on it.
<roaksoax> smoser: right but that's a different feature that can lie on top of
<smoser> on top of?
<smoser> on top of what.
<roaksoax> smoser: the work that's being done now
<smoser> what work is that ? i'm really sorry for being late to the party.
<roaksoax> smoser: the work on adding support for other ubuntu releases
<smoser> but i really dont know what value a "release" field for a node has.
<smoser> the only thing i can imagine is with reguard to commissioning and ephemeral environment.
<smoser> but then, things get complex quickly.
<smoser> as i'd only think those things are useful if i can expect behavior out of them.
<roaksoax> smoser: right, but IMHO, you should be able to know what machines deploy what OS version
<roaksoax> smoser: and that should be stored on the DB
<smoser> roaksoax, they deploy the version that someone asked for
<roaksoax> smoser: selecting a machine and telling what to install on it, is a different feature, but yet, it requires a DB filed
<smoser> it does not.
<smoser> its an api call.
<roaksoax> smoser: yes, you can ask that on the WEbUI or you can ask that on the api
<smoser> "OS version" is not an attribute of a node.
<roaksoax> smoser: it is now
<smoser> it is an attribute of an instance
<roaksoax> smoser: and it should be
<smoser> no.
<roaksoax> smoser: we cannot completely treat a machine as an instance
<smoser> other than the case of "ephemeral" and "commissioning"
<smoser> why not?
<roaksoax> smoser: so then that defeats the purpose of inventory
<smoser> no.
<smoser> it does not.
<roaksoax> smoser: when you do inventory you know what machines have what
<roaksoax> smoser: on inventory you *know* what machine has *what* OS on it
<roaksoax> smoser: and that's stored in the DB
<roaksoax> smoser: and after you deploy something, you need to know what
<roaksoax> smoser: and after you deploy something, you need to know what's installed in that machine, and that information is stored in the DB
<roaksoax> it is an attribute of a node
<smoser> see i dont think it is
<smoser> "default" for that node (which would only really have value in ephemeral / commissioning)
<smoser> is a derived value based on the hardware you know about in that node
<smoser> and "currently installed" is a attribute of the "instance" that is currently running on that node.
<roaksoax> smoser: right, where do you store a currently installed value?
<smoser> this is the bug i opened for this.
<smoser> https://bugs.launchpad.net/maas/+bug/944325
<ubot5> Ubuntu bug 944325 in MAAS "no separation of instance id from node id" [Low,Triaged]
<roaksoax> smoser: you have to store that info in the node
<smoser> which is broken.
<smoser> and your suggestion of inventory is busted anyway.
<smoser> an OS version can be 'distro-upgraded'
<smoser> and made invalid
<smoser> or turned into RH
<smoser> so you can't *actually* assume much out of that.
<smoser> so.
<smoser> i relaize you just want a fix for this now.
<smoser> and that we're apparently hnot going to get an "instance" table for 12.10.
<roaksoax> smoser: ok so this means we are always going to treat maas as ec2 on physucal machines then
<smoser> not really.
<roaksoax> it is, if you are looking for a provider that gives you X with Y release
<smoser> a specific installation (for user 'bob' rather than user 'fred') is somewhat important to represent.
<roaksoax> then it is the same on ec2 when you ask for X with Y release
<roaksoax> smoser: i personally don't think ew can simply address thjis as whatever machine with X release
<roaksoax> we should be able to select what machines I want to be deployed with X release
<smoser> sure. thats fine.
<smoser> ok.
<smoser> so.
<smoser> here... let me have a few minutes to more clearly write down what i think. and we can put that in a etherpad.
<roaksoax> smoser: so simply enough , forget about API and Juju "If I want node-XYZ to be deployed with Precise, I should be able to do so fro the WebIU, which is what I'm aruguing"
<roaksoax> smoser: and not saying that what you are syaing shouldn't be done
<roaksoax> smoser: but what I'm arguing means that I need to be able to select the release for the node I'm wanting to deploy
 * roaksoax needs to run, bbl
<smoser> roaksoax, rvba http://pad.daviey.com/server-maas-release-support
<smoser> thats my collected thoughts.
<smoser> rvba, but i'd be more than delighted if you said "oh, we really need to have the notion of 'instance'" and just implemented that.
<rvba> smoser: thanks for that.  I need to step out right now but I'll have a look at your summary.
#maas 2012-09-11
<jtv> bigjools: you up for a quick chat about the way we'll register installed boot images?
<jtv> Blast.  Test failures in trunk.
<jam> bigjools: I think having some time of a 3-4 person standup, separate from a 8-person standup is reasonable.
<bigjools> jam: exactly what I was thinking :)
<bigjools> jam: do you want to come in in about 10-15 mins then?
<Daviey> the more the merrier, and distracting !
<bigjools> Daviey: just the man
<Daviey> oh dear
<bigjools> Daviey: my upgrade to quantal has seriously fucked my installation
<Daviey> rocking
<Daviey> any more detail?
<bigjools> $ dpkg -l
<bigjools> dpkg-query: error: parsing file '/var/lib/dpkg/status' near line 56897 package 'libao4:i386':
<bigjools>  mixed non-coinstallable and coinstallable package instances present
<bigjools> and a crapload of broken dependencies :/
<Daviey> wow, that is quite spectacular
<bigjools> thanks :)
<jam> bigjools: sounds good
<Daviey> bigjools: fancy raising a bug, and including all this output?
<bigjools> jam: cool
<bigjools> Daviey: yeah
<Daviey> bigjools: just raise it against 'Ubuntu'
<bigjools> Daviey: ok, shall I assign you? :)
<Daviey> bigjools: I suspect it's one that cjwatson will be better suited :)
<bigjools> heh
<Daviey> i'm just a dumb mangler.
<bigjools> jam, jelmer, mgz: https://plus.google.com/hangouts/_/c667fc896a4dfdbabcd78a47a4018ee6c2cb7341?authuser=0&hl=en-GB
<mgz> ta
<jam> bigjools: I don't think i have access rights to modify the Maas board, can you add the Story 3 lane?
<jam> ah, there it is, nm
<bigjools> jam: you should have all the rights you need, let me know if you need more
<jam> Daviey: you were asking about mongo auth. I have a summary of it, would you like it here or on Maas-devel?
<Daviey> jam: mailing list might be more useful for historic and wider audience
<roaksoax> morning
<bigjools> o/ roaksoax
<roaksoax> o/ bigjools
<smoser> roaksoax, rvba did you get a chance to read http://pad.daviey.com/server-maas-release-support ?
<smoser> do you have som time to talk about it?
<roaksoax> smoser: yeah I skimmed through it
<roaksoax> smoser: i, hoewver, think you should probably post your proposal on the ML
<roaksoax> smoser: i'll drop my patches but I don't think whether there's time to get that into quantal
<smoser> well ,we  can do that. but we can surely have people tell me what they think is wrong first.
<roaksoax> smoser: well personally I still think we should be able to select what node should have what release, I think we can support both approaches... but if you consider my approach is incorrect i give in in favor to yours
<rvba> smoser: I think your proposal makes sense.  Let's post it to the list to see what people think.
<rvba> That problem was briefly mentioned during our standup call this morning.
<rvba> People seen to think that having the ability to tell that a particular node will used a particular release before deploy time is superfluous.
<rvba> s/seen/seem/
<rvba> roaksoax: ^
<roaksoax> k
<roaksoax> as I said, I give in
<roaksoax> i guess that now making sure that smoser's proposal or anhy other fix for the issue gets into quantal is a priority
<rvba> yep
<roaksoax> but not having quantal support is a blocker for me, so my tasks will be blocked until ya'll have the support implemented
<roaksoax> smoser: ^^
<smoser> roaksoax, i dont understand "we should be able to select what node should have what release, I think we can support both approaches"
<smoser> how does my approach not do that?
<roaksoax> smoser: your approach is telling the api to give you a node with a particular release
<smoser> well, no.
<smoser> i think that is a requirement
<rvba> roaksoax: you can add the global default stuff, that alone will allow you to test stuff.  And it will be one step in the right direction.
<smoser> but that is not related to this actually.
<smoser> we dont have an api entry point now for "give me a node"
<smoser> we only have "start" on a particular node
<smoser> so, unaddressed is "just give me a node already!"
<roaksoax> smoser: exactly, so that's what i mean. start a node an install XYZ release on it
<smoser> i'm confused.
<smoser> my approach has that.
<roaksoax> smoser: yes
<roaksoax> smoser: that's what I'm saying
<roaksoax> i'm talking about your approach
<roaksoax> smoser: so on the WebUI, when you do "start node" how can you tell it what release to use if you want a different from the default?
<roaksoax> smoser: in your appraoch is not possible to do that because the way you are considering to do this is doing so through the API
<roaksoax> smoser: so in order to do it, you still need to tell the node what release to use, it might not be an attribute of the node, but you still need to tell it
<roaksoax> smoser: and that should be stored somewhere
<smoser> well it is stored somewhere.
<rvba> roaksoax: the usage of the WebUI to start a node was always considered a very special case primarily meant for testing.
<smoser> on the node
<smoser> "default_release" as i said.
<rvba> The API story is the real one.
<roaksoax> rvba: right, but the usage is there
<roaksoax> rvba: it is out to the wild
<roaksoax> rvba: so you need to provide the same functionality in both interfaces
<roaksoax> smoser: yes, defualt_release is very broad...
<rvba> I think it is ok to say that using the webUI will use the default for now.  And refine later if we need to.
<roaksoax> rvba: i think by doing that you are removing functionality
<roaksoax> rvba: and another problem is make it place nicely with juju
<roaksoax> rvba: for 12.10
<rvba> Exactly, but Juju uses the API.
<roaksoax> rvba: while the WebUI might be a simplified interface to interact with MAAS, I think it is essential to be able to support a release
<roaksoax> rvba: so when you start a node, you node that that node will use X release you want
<rvba> roaksoax: we can add this in the WebUI as well (dropdown menu next to the start button or something)
<rvba> Let's focus on the core functionality first, then the API, and only then the UI.
<roaksoax> rvba: ok, well the start button on the UI uses the API right?
<rvba> roaksoax: not directly.
<rvba> roaksoax: well, sorry, not at all.
<roaksoax> rvba: well then we would just simply need to figure out how to pass the release dynamically without relying on having it stored somewhere
<rvba> roaksoax: indeed.
<roaksoax> rvba: if I find the time I'll look into it, unfortunately i need to concentrate on other stuff atm
<rvba> roaksoax: first step would be to add the default I think.
<rvba> roaksoax: you've done most of the work for that already I think.
<roaksoax> rvba: yeah the default stuff is just a couple lines, i'll separate the patches and see to it
<rvba> roaksoax: cool.
<smoser> i will send proposal to list.
* flacoste changed the topic of #maas to: 4 weeks until Final Freeze | Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/
<bigjools> why am I still up
<jelmer> it's a mystery
<smoser> roaksoax, ok. so interesting problem here.
<smoser> i just booted a ephemeral image in a kvm instance.
<smoser> instance had (i think 256 M of memory) or some small ish number.
<smoser> apt-get update runs
<smoser> apt-get update writes 115M to /var/lib/apt/lists
<smoser> which in ephemeral instance consumes 115M of memory
<smoser> ie, i see some real potential issues here.
<smoser> Daviey, you  might find that interesting also.
<smoser> i suspect that 2G memory is the minimum "real server" size
<smoser> but for test within vms, thats a bit annoying.
<Daviey> smoser: hmm.. do you think we might need to back the overlayfs via networking ?
<smoser> i dont know. we coudl back it via block device exposed over iscsi
<Daviey> yeah
<Daviey> not urgent for 12.10 IMO
<Daviey> but next cycle, we might need to consider something smarter?
<smoser> yeah
<roaksoax> smoser: interesting
<smoser> we can improve that speicifically fairly easily, by removing i386 from and64 arch
<roaksoax> smoser: during commissioning, do we actually need anything from apt?
<smoser> and removing deb-src lines
<roaksoax> smoser: right, so the only reson why it is being run is for maas-enlist right?
<roaksoax> apt* being run
<smoser> well..sort of.
<smoser> commissioning is intended to be a general purpose environment
<smoser> so you'd expect it to work.
<roaksoax> smoser: right, well we don't really need deb-src
<roaksoax> allenap: still around?
<allenap> roaksoax: Yes :)
<roaksoax> allenap: so maybe yoy'll be able to help me
<roaksoax> allenap: where is it that when you try to start a node, it sends the data to generate the preseed for a particular node?
<roaksoax> allenap: or whats the entry point from the node and the generation of the tftp parameters it should use, such as arch, releaes, etc
<jam> I'm trying to run 'make' but ipython.scypi.org seems to refuse all connections.
<jam> Is there another option?
<allenap> jam: Install ipython locally ought to solve it. Failing that, the tarball can be put in your buildout cache (I can send it to you).
<allenap> (We kind of need a better solution for that.)
<roaksoax> allenap: is that api.py?
<jam> allenap: wasn't that the 'download-cache' discussion?
<allenap> jam: Yes.
<mgz> or ignoring it an installing from archive works if the version matches
<allenap> Right, what mgz said; that's what I was fat-fistedly trying to say with "install ... locally" :)
<jam> mgz: there is a strong debate that you should ignore system packages so that the build environment enforces strict dependencies.
<mgz> (I had that for nosetests who's blog(?!) buildout was failing to scrape on make))
<jam> allenap: 'apt-get install ipython; make' still fails
<jam> still is trying to download ipython
<jam> (on Precise)
<allenap> jam: buildout will enforce strict dependencies because allow-picked-version is false, but if they match it'll use it.
<allenap> Oh buildout, how you ***FEFEGEg4%$^$ me.
<jam> allenap: how do I know what version buildout is wanting?
<allenap> jam: versions.cfg ought to say.
<jam> allenap: ah, buildout wants 0.12, and I have 0.12.1 ... :(
<jam> hacking that makes it get  further at least
<allenap> jam: http://ubuntuone.com/6HXrvwiGY2qRqKyezMmVYZ for 0.12
<jam> if only I could easily copy that to another machine :). But I'll make it work
<allenap> For the egg. Put it in ~/.buildout/cache/dist
<jam> it still is getting selenium, and, and
<jam> allenap: I don't have a ~/.buildout
<jam> is it reasonably safe to just create it?
<allenap> jam: Ah, that's worth having. See HACKING.txt about it.
<jam> (I wasn't following the discussion that closely.)
<roaksoax> smoser: so I still see no easy way to get the release stuff
<roaksoax> smoser: rather tahn continue to do what we were doing
<roaksoax> because when the preseed is presented or the parameters for tftp boot, the only thing we really send is the Node
<allenap> roaksoax: So, got distracted.
<allenap> roaksoax: pxeconfig() in maasserver.api creates  KernelParameters object, which has various boot-related things in it.
<allenap> It doesn't generate the preseed though.
<roaksoax> allenap: so the problme is this
<roaksoax> allenap: hold on (meeting :) )
<roaksoax> allenap: ok, so the issue is this: In order to add releases support, I added a new attribute to the Node as os_release. However, after discussing it with smoser , he mentioned that we should not have an attribute for the node
<roaksoax> allenap: but rather we should simply specify the release we want the node to boot into
<roaksoax> allenap: and that's it
<roaksoax> allenap: so the priblem now becomes, how can we dynamically have that value (the release to use), if we only pass objects ot preseed.py
<roaksoax> allenap: we can't pass a globally set value right? since we need it for a particular node
<roaksoax> allenap: the only easy solution i see is simply saying "the release for X node on deployment will be Y" but I don't see how to pass that Y if we are passing objects
<allenap> roaksoax: I think we need to store this on the node, as you've done.
<roaksoax> allenap: yeah that's the only solutio I see
<roaksoax> allenap: I just needed another opinion
<allenap> roaksoax: smoser's right in that it's only used during the first boot after a machine has been allocated, and that once the machine has correctly installed and pinged maas to say "stop netbooting me" it's no longer relevant, but we need to keep it somewhere until that ping is done.
<smoser> allenap, shouldn't we be able to add a getter to the object?
<smoser> that does something more complex than just look at that attribute of the node?
<allenap> But there isn't yet a better place to put it. We will at some point model "allocations", at which point I guess we can move it to there.
<smoser> it just really isnt an attribute of a node
<smoser> operating systems != hardware
<smoser> (unless you come from apple)
<allenap> smoser: Node is overloaded so I'm not sure where else to store the choice of OS right now. We need to remodel. Perhaps something like: board -< node >- allocation, or something like that.
<smoser> board ?
<smoser> so.
<smoser> the one thing i really care about here.
<smoser> is the external interface
<smoser> 'start' simply needs to take "release"
<allenap> smoser: For reconfigurable hardware... so "future".
<smoser> and having the user have to change a node attribute in order to do that seems completely broken
<roaksoax> smoser: ok so, the problme is thta basically, in ordfer to create the tftp/pxe stuff we only use the node attributes, right?
<allenap> smoser: It probably ought to be an argument to the "acquire" call.
<roaksoax> smoser: so we need a way to tell "NodeXYZ will deploy with ABC release"
<allenap> "start" and "stop" are just power related; they don't imply OS installation.
<roaksoax> smoser: this means that each node object needs to know what release is related when it gets started
<roaksoax> smoser: so it is either have database table/class that matches Node <-> Instance release version, or keep it as an attributed, but treat it as an instance
<roaksoax> smoser: I don't know if I explained myself clearly :)
<smoser> allenap, hm..
<smoser> i thought start becuase i thoguht userdata was attachedk to start
<smoser> but i could have been wrong
<allenap> User will call MAAS and say "I want an amd64 node running Quantal" (== the acquire call), MAAS will store the user and release on the Node record, turn netbooting on, mark it as allocated, and reboot the node.
<smoser> what is the link for do con the api?
<allenap> Argh, you're right, start() does take the user data.
<allenap> acquire doesn't do the boot; you need to acquire and start in sequence.
<roaksoax> whilke start_nodes() does take the user data, it sets that data as to the node right?
<roaksoax> NodeUserData.objects.set_user_data(node, user_data)
<roaksoax> but that's for the metadata server
<allenap> roaksoax: Yes, essentially. There are only ever zero or one NodeUserData rows for a node.
<allenap> I have to go now, but I'll be back in about 2h.
<roaksoax> allenap: alright
<roaksoax> thanks!
<smoser> ugh.
<smoser> so. the big thing to me is that whatever takes user-data should take release.
<smoser> from the api perspective.
<roaksoax> smoser: right, but that user-data is for meta-data server, not for the preseed/tftp boot generation stuff
<roaksoax> smoser: the preseed/tftp takes a Node object
<smoser> but thats just garbage implementation
<smoser> just implementation
<smoser> the consumer should not think of those things as separate.
<roaksoax> smoser: right, so the user-data is set as Data for the node right? but that's meta-data server stuff. Unless you want to do the same for the preseed...
<smoser> well the user doesn's specify preseed.
<smoser> so i dont really care
<smoser> but user-data and release need to be exposed via api
<roaksoax> smoser: right, but the thing is "how to you match a node object with a piece of data (release)"
<roaksoax> smoser: so that when the preseed/tftp url generation happens, it uses the correct data for  *that* node
<roaksoax> smoser: atm, it seems much easier to keep a node attribute for release and when you do "give me a node and install X on it" then it should just simply get a node and set the os_release attribute to the release you are requesting
<smoser> but that is just completely broken from the api perspective.
<roaksoax> smoser: i agree might not be the best approach, but it is a similar approach to what cobbler did
<roaksoax> smoser: in cobbler you simply told it "this system inherits from profile X, and profile X is Y release"
<smoser> i dont think thats going to win you any fans.
<smoser> saying "cobbler did it that way" as a response to "thats not the right way"
<roaksoax> smoser: I'm not arguing that because cobbler did it, we should do it that way. I'm arguing that we need a way to add handle this fast as upstream is busy with other stuff, I need to get other stuff done, and i'm sure you also need to
<roaksoax> smoser: so, i'm saying can we provide a more appropriate fix with the time constraints that we face?
<roaksoax> smoser: since you said you requested an "instance" type of handling for MAAS, but they were not going to make it happen for 12.10
<roaksoax> smoser: so the release stuff would be part of that "instace" approach within MAAS, right?
<roaksoax> smoser: on fwiw, in cobbler you could say "deploy this machine with X release, or deploy this machine with Y release using its api (using koan)"
<roaksoax> smoser: but anyways, I'm maybe to dumb to see  a fix for it (at the moment) that doesn't involve having to store an attribute for a Node object
<smoser> suck.
<smoser> then we could ammend  my suggestion by having an "instance release" that default ed to "node release' that defaulted to "global release"
<smoser> and instance release would be set to NULL on "return/destroy" (whatever that api call is called)
<roaksoax> smoser: as a node attribute?
<smoser> well, my proposal was that those things were node attributes, yes.
<smoser> (the proposal to the list)
<smoser> i suggested that we would have a node attribute for "release"
<smoser> that would default to the global release.
<roaksoax> smoser: ok hold on, I'm confused now
<roaksoax> smoser: the support that was hacked for that was basically this: Have a os_release attribute for a Node (similarly to architecture, power type). Every time we enlist a node, the os_release would be set to a globally default release
<roaksoax> smoser: so what I was suggesting now was that if we simply specify a release different than default, it would set node.os_release as the new requested release, and deploy with that
<roaksoax> smoser: and on a release, that could be set back to default
<roaksoax> smoser: is that what you were looking for?
<smoser> well, maybe for now that is sufficient.
<roaksoax> smoser: but if that's what you were proposing, then the support I added does that almost the same. The only difference is that I was setting a default release for both, commissioning/enlistment and deployment
<roaksoax> smoser: which can obviously be easily changed
<smoser> well, i think you need to differenciate between commissioning/enlistment and install
<smoser> so keep that.
<roaksoax> smoser: right, that's simple to do
<roaksoax> smoser: what I was trying to look a solution for is the attribute (os_release) for the node
<roaksoax> smoser: which I thought you didn't want at all
<smoser> outside of another table ("instance"), which i think is the correct long term path, i dont think there is one.
<smoser> so what i was suggesting is largely what you are doing
<smoser> except for the fact that i do not want specifying "release" in start to change the node.
<smoser> which you're accomplishing by setting it back to 'default' on release.
<smoser> which ... is somewhat lossy
<smoser> but not that bad.
<smoser> ie, if it the default "install" for that node had been set to 12.10 for good reason
<smoser> and i specify 13.04 for one install
<smoser> and then on release maas puts it back to 12.04 (the global default)
<smoser> we've lost data.
<smoser> the only way i can see to work around that is to not set the default for the node, but on start to set a "install_release"
<smoser> and unset *that* on release.
<roaksoax> smoser: right
<roaksoax> smoser: but that's the thing, on start(), calls start_nodes(), which could take a release and set node.os_release = "whatever release passed"
<roaksoax> smoser: http://paste.ubuntu.com/1199137/ or similar
<roaksoax> smoser:so then the "instance" view of a node would be simple a NodeInstace that inherits from Node? which is able to hanlde user-data?
<smoser> "instance" view?
<smoser> roaksoax,
<roaksoax> smoser: i mean, what you refer as treating nodes deployments as intances
<roaksoax> smoser: i mean, just wondering how did you envisoned this?
<smoser> well, i basically consider a "install -> release" cycle an "instance"
<smoser> and an "instance" would have user-data specific to it and a user that owned the instance
<smoser> and a release that was installed
<smoser> and a start and end date
<roaksoax> smoser: ok, so how do you start a node thorugh the API?
<smoser> look at juju i think.
<roaksoax> smoser: I think I just spotted another issue
<roaksoax> smoser: not that it matters much, yet but if the node has not being deployed yet, obtaining the preseed would display the preseed for the default release
<roaksoax> smoser: unless we specify a release specifically i guess
<roaksoax> smoser: it will indeed require lot of refactoring I believe
<roaksoax> i guess we will leave that for upstream :)
<smoser> yeah, i dont think thats an issue really.
<roaksoax> smoser: ok, so another problme is this
<roaksoax> smoser: when a node makes a PXE request, the request grabs the MAC address of the node making the request
<roaksoax> smoser: and by using the mac address it obtains the node
<roaksoax> smoser: and with that node it generates the kernel command line
<roaksoax> smoser: so the release *has* to be stored somewhere for that particular node
<roaksoax> smoser: because the way this happes is by making a post request
<roaksoax> smoser: unless, we could obtain the relese from that post request somehow
<roaksoax> smoser: oh no way, we can't, cause the request is being made by a node itself after you tell the node to start
<smoser> roaksoax, you've confused me.
<smoser> roaksoax, i dont see a problem in the above.
<smoser> if there were an "instances" table, there would be a way to get the "current" instance htat occupied a node.
<smoser> so essentially, a node would have a os release but only because of hte instance currently occupying it.
<smoser> which woudl hvae been created on the start
<roaksoax> smoser: right, but look at src/maasserver/api.py:pxeconfig
<smoser> roaksoax, right. thats fine.
<smoser> i'm missing something
<smoser> i'm sorry
<roaksoax> smoser: so it gets the MAC address of the machine that has made the request, it searches for a node within MAAS. If found, it uses its attributes to create the params to be granted by the pxe file
<smoser> right.
<smoser> so yes, i agree. that means that given a node you have to be able to come up with the correct kernel/initramdisk/state
<smoser> but thats not bad.
<roaksoax> smoser: righjt, so there, there's two options, keep the os_release attribute of a node
<roaksoax> smoser: or, once a node is found based on its mac, then we would need to map the node to somewhere else to obtain the release, right?
<roaksoax> smoser: so if we have user data for the node, then first we need the node, then we need that node's user-data and then we need the release
<smoser> right.
<smoser> that is fine.
<smoser> given a node, there will only ever be one "instance" at a given point in time.
<smoser> and that instance would have release and user-data
<roaksoax> smoser: right, so the way I was fixing that is: release = node.get_os_release()
<smoser> so assuming mac is unique (which we have assumed), at a given point in time a MAC can map to user-data or os-release thorugh node
<roaksoax> smoser: so, do you think that the Node class should have an attribute (which might be called instance_data, that contains the release)
<roaksoax> so when you call: node.get_os_release(), which we can rename to: node.get_install_release(), it will search for the release in that instance_data variable and return it, if not found, simply return the default?
<smoser> no.
<smoser> roaksoax, for your work i tihnk i'd just hack the way you are
<smoser> the longer term fix is another table "instances" where an instance maps N:1 to nodes.
<smoser> and somehow you can look up "current" instance for a node.
<smoser> and that instance has "os_release" and such
<smoser> but your solution for now is ifne i think.
<smoser> so dont get more complex than you need.
<roaksoax> smoser: right, that's my question. Where does that "instances" table live?
<smoser> it seems we are knowingly shortcutting
<roaksoax> or should live
<smoser> well its a object i think
<roaksoax> smoser: an object that would be instanciated within a node, or separately?
<smoser> separately i thikn. but i dont knwo tha ti understand thequestion.
<smoser> it has to be separate though
<roaksoax> smoser: ok, but, there should only be 1 instance for 1 node, hence a 1:1 relation, shouldn't it? BEcause 1 node can only have 1 instance at a time
<smoser> but over history there are N
<smoser> and you want to be able to look at historic ones
<smoser> for accounting
<roaksoax> smoser: are we looking to make an instance a database entry?
<smoser> i would think so
<smoser> but i'm not sure how such releations are normally modelled.
<smoser> ie, how you would normally indicate "current" on something like that.
<roaksoax> smoser: right. Yeah cause I thought we wouldn't care how many times has that node been deployed in what release or for what purpose
<smoser> roaksoax, see that bug i opened.
<smoser> you'd want to know that for accounting
<smoser> you want to know that bob uses 90% of your cpu time
<smoser> or that only 8% of your cpu used run 10.04
<roaksoax> smoser: right
<smoser> or that 68% of your total cpu time is unused
<smoser> and you cant do that without history (or at least keeping the count at the moment of acquire and release)
<smoser> but i think you just keep the whole records instead
<roaksoax> right
<roaksoax> smoser: stil around?
#maas 2012-09-12
<smoser> here now roaksoax
<jtv> bigjools: I guess my fix for bug 1049407 should go into two branches now?
<ubot5> Launchpad bug 1049407 in MAAS "DHCP next-server set incorrectly on multi-homed hosts" [Critical,In progress] https://launchpad.net/bugs/1049407
<bigjools> jtv: how's that?
<bigjools> oh you mean backport
<bigjools> yes
<jtv> You couldn't have waited half a lousy day with that branch, could you?  :)
<bigjools> jtv: well the part that lets you set a maas-facing url needs to go in both
<bigjools> anything to do with dhcp only in the backport branch
<bigjools> since rvb is doing a generic solution for 12.10
<jtv> What solution is that?
<bigjools> jtv: I *could* have :)
<jtv> Grrrr
<bigjools> the cluster enlistment process will detect all interfaces on the cluster host and ask the admin to pick one
<jtv> Shouldn't that become the setting for the maas-facing URL then?
<bigjools> no
<bigjools> cluster vs region here remember
<jtv> Oh, you mean because the node won't be talking to the region controller anyway?
<bigjools> these are completely different things we're talking abouty
<bigjools> the master worker (aka master cluster) can make assumptions that it can use the maas-facing address's interface
<bigjools> remote clusters need to be explicitly set up
<jtv> Well either way, I think get_maas_facing_server_address() needs to make use of a different setting â and that should be the whole of the fix to this particular problem.  So I don't foresee any changes that would not be suitable for trunk.
<jtv> Although I do think there are more places where we should explicitly use the maas-facing address.
<jam> jtv: https://code.launchpad.net/~jtv/maas/bug-1049407/+merge/123891 seems incomplete
<ubot5> Ubuntu bug 123891 in firefox (Ubuntu) "No spelling suggestions on right click" [Undecided,Invalid]
<jam> it only has comment changes
<jtv> jam: looking
<jtv> jam: you mean the MP where the commit message says, âThere were no changes to make, but I found some comments that could be clearer.â  Right?  :-)
<jam> jtv : I skipped to the 'pre implementation with Julian' which made me think there were actual changes.
<jam> Not sure why you would need a preimpl for comment only.  But hey, +1 from me :)
<jtv> The pre-imp had to establish that no changes were needed!  Thanks.
<jam> jtv: I read it from the email
<jam> not the Commit message
<jam> but just the Description
<jam> apparently Commit Message doesn't get sent via email
<jam> which is why I didn't see it.
<jtv> :(
<jtv> The latest wisdom is that the commit message should be descriptive.
<jam> I agree it should be descriptive
<jam> I'm not sure that the LP infrastructure handles it properly
<jam> I tend to review via email
<jam> I'll try to be on the lookout for it.
<bigjools> commit message doesn't get sent if put on at the MP creation time
<jtv> Sorry about that.  Maybe I should just say "see commit message" in the description to avoid these mistakes.  Copying the commit message seems wrong.
<bigjools> :(
<jam> jtv: that probably would help while we transition, at least.
<jam> bigjools: I see this is a known issue: https://bugs.launchpad.net/launchpad/+bug/1017293
<ubot5> Ubuntu bug 1017293 in Launchpad itself "Commit message is not shown on the initial merge proposal email" [High,Triaged]
<bigjools> jam: yeah look who filed it :)
<jam> yeah, I saw that
<bigjools> jam, jelmer, mgz https://plus.google.com/hangouts/_/b97be36d9d774b00fb757d4aea1e57f788c80227?hl=en-GB
<bigjools> back later
<allenap> bigjools: I have to go out. We did a catch-up yesterday, so can we postpone today's?
<jam> jtv: i'm happy to continue chatting, I just didn't want to tie up both teams
<jtv> fair enough!
<jtv> I was just saying: somebody might have implemented auto-tuning for either data store.
<bigjools> allenap: yeah find
<bigjools> fine*
<mgz> and again today, yeay buildout...
<mgz> Download error on http://www.liucougar.net/blog/nose-subunit: [Errno -2] Name or service not known -- Some packages may not be found!
<mgz> jtv: have made the tweaks you suggested in the review
<roaksoax> jtv: around?
<roaksoax> rvba: howdy! So while I was talking to smoser yesterday I think we've reached a concensus on how the release should be implmeneted
<roaksoax> rvba: so, we will have default_commissioning_release and default_install_release. We will keep the os_release attribute until the "instace" approach/table exists. The release will be set on start() and switched back to default on stop()
<roaksoax> rvba: we will obtain the release with get_install_release and we will set it with set_install_release. That way, once the instances approach smoser was mentioned exists, we can simply replace the get_install_release more easily and ditch the set_install_release
<roaksoax> rvba: thoughts?
<roaksoax> smoser: agreed?^^
<smoser> its reasonable. although you can just use a getter and setter (rather than get_install_release and set_install_release but do whatever is done in MAAS).
<roaksoax> smoser: alright, cool then
<smoser> roaksoax, is maas uninstallable right now ?
<smoser> http://paste.ubuntu.com/1200553/
<roaksoax> smoser: where are you installing from? daily?
<smoser> http://paste.ubuntu.com/1200556/
<roaksoax> smoser: it shouldn't be...
<roaksoax> smoser: do you have maas already installed?
<rvba> roaksoax: hey
<smoser> it says Installed: none
<rvba> roaksoax: "and switched back to default on stop()" you mean switched back to None don't you?
<rvba> roaksoax: in the approach you describe, node.os_release will be used to store the current release for a running instance right?
<roaksoax> rvba: yes. So it will have its default, say precise, but if on start we pass quantal, it should be updated. on stop, it should be rolled back to precise (or the default)
<roaksoax> rvba: btw... http://pastebin.ubuntu.com/1200559/
<rvba> roaksoax: before the instance is even started, what will the os_release field contain?
<roaksoax> rvba: the one being set as default
<roaksoax> rvba: the config default
<rvba> roaksoax: specific to this node?
<roaksoax> rvba: global one
<roaksoax> rvba: all nodes iwll be enlisted and set a default release
<roaksoax> rvba: so if through the api a node is requested and no release is specified,it will use the default. If a release is specified, it will use that specified release
<roaksoax> rvba: any ideas on the pastebin?
<rvba> roaksoax: that API behavior seems fine to me but since we don't what to support setting a release to be used at the node level before deploy-time, I suggest having that field None when the node is not yet deployed.
<rvba> roaksoax: let me have a look.
<rvba> roaksoax: yes, apparently there is a bug in South and it believes that the nodegroup.uuid field is new and that's not the case.  I'll fix that soon but in the meantime: select 2, enter the empty string, then, in the created file, edit out the two lines (one in forward() and one in backward()) which talk about that uuid.
<roaksoax> rvba: cool thanks
<roaksoax> smoser: package doesn't seem broken to me btw
<smoser> hm.
<roaksoax> rvba: so where is it, or how is it that the WebUI starts a node?
<roaksoax> if it doens't use the API for that
<rvba> roaksoax: let me check
<rvba> roaksoax: have a look at src/maasserver/node_action.py:StartNode
<roaksoax> rvba: btw.. there's no way to test the start and stop of a node through the api right?
<roaksoax> as in, actually test it
<roaksoax> (manually)
<rvba> roaksoax: src/maasserver/api.py:NodeHandler.start
<roaksoax> rvba: right, but what I mean, is there a CLI ?
<roaksoax> rvba: that doesn't involve me hacking around to get it to work
<rvba> roaksoax: not yet, the CLI is coming up, allenap is working on it atm.
<roaksoax> ok cool
<roaksoax> allenap: does your cli already start nodes?
<rvba> roaksoax: the CLI will expose all the API methods.
<allenap> roaksoax: It will, but doesn't yet.
<roaksoax> allenap: ok thanks
<roaksoax> rvba: so we can handle the selection of release once the cli is in place cause we also need the same for juju
<roaksoax> rvba: so can can I get the state of a node object?
<roaksoax> rvba: self.status?
<roaksoax> err node.status?
<rvba> roaksoax: yes
<smoser> roaksoax, it most certainly seems to me that maas in arhcive is uninstallable
<roaksoax> smoser: why would it be uninstallable if the only change on ubuntu2 against ubuntu1 is simply a change within a file
<smoser> it seems python-twisted is currently uninstallable
<roaksoax> smoser: ahh then that's the problem
<mgz> don't we have archive testing to prevent that kind of thing... :P
<roaksoax> rvba: so, on the model, we should not set a default for os_release then?
<roaksoax> rvba: so instead of :
<roaksoax> os_release = CharField( max_length=10, choices=UBUNTU_RELEASE_CHOICES, null=True, blank=True, default=UBUNTU_RELEASE.default)
<roaksoax> leave it as :
<roaksoax> os_release = CharField( max_length=10, choices=UBUNTU_RELEASE_CHOICES, null=True, blank=True)
<roaksoax> ?
<rvba> roaksoax: well, I think we should set a default of None.  This will indicate that, when a node is created, there is no running ubuntu installation on it.
<roaksoax> rvba: ok cool
<roaksoax> rvba: ok so, so far this looks like this: http://paste.ubuntu.com/1200725/
<rvba> roaksoax: you got me confused a bit I must say :).  Is node.os_release used to : a) store the release which is going to be installed when that node will get deployed or b) store the deployed release when this node will get deployed?
<roaksoax> rvba: a&b. It will store the release the node will be deployed with if different from the default one
<roaksoax> rvba: if no release is specified, then it will use the default
<roaksoax> (still need to change get_install_release)
<rvba> roaksoax: then consider this: a node has os_release='quantal' and the default is 'precise'.
<roaksoax> rvba: it will deploy quantal
<rvba> roaksoax: if someone deploys that node with an APi call and specifies release=precise.
<roaksoax> rvba: it will install precise
<rvba> roaksoax: then node.os_release will be changed to precise right?
<roaksoax> rvba: yes
<roaksoax> rvba: that part hasn't been coded yet as I'd like to have the CLI in place first
<rvba> And now, let's say the nodes gets 'released' or undeployed.
<roaksoax> rvba: os_release will be changed back to None
<rvba> How do you restore the original setting of 'quantal' ?
<roaksoax> rvba: initially it will have None, unless you change that on the WebUI
<rvba> roaksoax: so let's say someone changed that to quantal, you want to restore that when the node is released, even if it was deployed with another release right?
<roaksoax> rvba: so let me put it some other way
<roaksoax> rvba: case 1: node.os_release is None default is precise after enlistment/commissioning
<roaksoax> rvba: on install if quantal is specified, then it will deploy quantal, node.os_release will be set to 'quantal'
<roaksoax> rvba: on release. node.os_release will be set back to None
<rvba> That makes perfect sense.
<roaksoax> so if we deploy that node again and we don't specify the release, then it will deploy the default
<roaksoax> rvba: now, we have to consider a second case
<roaksoax> rvba: Case 2: node.os_release is None, default is precise.
<roaksoax> before we deploy, I go to the WEbUI and I change from "Default Ubuntu Release" to Quantal, and save
<roaksoax> node.os_release will be 'quantal'
<roaksoax> rvba: so I go to the cli, and deploy *without* specifying a release
<roaksoax> it will deploy 'quantal'
<roaksoax> rvba: now, when I release, it will be set back to None
<roaksoax> however, if on CLI i deploy specifying 'precise', it will install precise instead of the preivoulsy saved value
<roaksoax> which was quantal
<roaksoax> on release, it will be set back to none
<roaksoax> rvba: doing this gives us the flexibility of being able to temporarily set a particular release for a node
<rvba> roaksoax: ok, so node.os_release is used to track the release of a running instance.  When a node is not deployed, node.os_release is None.
<roaksoax> rvba: exactly
<rvba> roaksoax: ok, makes perfect sense to me then.
<roaksoax> awesome then
<guimaluf> dam! when I'm installing a new node I'm get this : Configuring 'network-preseed' failed with error code 1; I've not change anything with networks config to stop working!
<guimaluf> I've restarted squid-deb-proxy but with no success
<jtv> Any reviewers in the house?  I'm EOD, but I still have some reviews up from yesterday that I'm quite eager to get some progress on.
<jtv> This is the oldest, which the others are based on: https://code.launchpad.net/~jtv/maas/bug-1025582-model/+merge/123679
<ubot5> Ubuntu bug 123679 in gnome-media (Ubuntu) "gnome-volume-control crashed with SIGSEGV" [Medium,Invalid]
 * roaksoax brb
<allenap> rvba: Regarding _API_DOC, I fear one of us is losing their mind. http://pastebin.ubuntu.com/1200807/ is a snippet of what's in trunk. It looks like the docs are cached fine, but never actually used.
<rvba> allenap: haha, you're right.  I misread what you were saying :)
<allenap> rvba: Phew :) I know it's not important, but it's one of those things that I couldn't let go of.
<guimaluf> please I need help, my maas server stop working out of nothing! I'm getting the following error in node syslog and in cobbler. maybe they are correlated http://pastebin.ubuntu.com/1200818/
<roaksoax> rvba: rvba still around?
<roaksoax> allenap: still around?
<allenap> roaksoax: I'll be back in ~1h.
<roaksoax> allenap: ok, thanks
<allenap> roaksoax: Hi, back sooner than I expected. What's up?
<roaksoax> allenap: I forgot :)
<roaksoax> allenap: ah yes, I remember now
<allenap> guimaluf: Something going into your preseed file has non-ASCII characters in it. Can you think of what that might be?
<roaksoax> allenap: so, I'm lookat at src/maasserver/api.py:start
<roaksoax> allenap: nodes = Node.objects.start_nodes
<roaksoax> allenap: 'nodes' contains only 1 node, or will /can contain several nodes?
<allenap> roaksoax: Yes, only one node. That start method is part of NodeHandler, so the context is a single node. However, we ought to have a start method on NodesHandler (note the plural) that will let us call start_nodes with more than one node.
<roaksoax> allenap: right, so I were to pass the release as part of the request to start()
<allenap> In general, we ought to think of the plural case always before the singular, but iirc the Juju machine provider interface expected to call start on one machine at a time, so that's what ended up getting written.
<roaksoax> allenap: do you think it should be done in start(), or in start_nodes()?
<roaksoax> allenap: such as: http://paste.ubuntu.com/1201070/
<allenap> roaksoax: I think that start() should be for *only* turning the power on, not for accepting user data. acquire() should accept user data, or there should be a separate way to set user data. I think start() has been wrongly overloaded here.
<roaksoax> allenap: right, that's a separate issue though :)
<roaksoax> allenap: anyways, that makes sense?
<roaksoax> allenap: though, note that for juju, acquire means "give me a system", and start means "start the acquired system with XYZ"
<roaksoax> allenap: so in the api, the start() servers for that
<allenap> roaksoax: Yes... your change adds to the things we have to change (it's fine otherwise). The problem is, as we change the API, we will have to change the Juju machine provider too, meaning more coding, reviews, etc. Right now it's more important to get the public face of the API correct than it is to add these features.
<roaksoax> serves*
<roaksoax> allenap: agreed
<allenap> Cool.
<roaksoax> allenap: ok so, in start() how can I set the a value for that particular node given that it doens't have the node instance
<allenap> roaksoax: You have the system_id for the Node, so you can get it.
<allenap> roaksoax: Look in the release method just below.
<roaksoax> allenap: so siumilar to this then? http://paste.ubuntu.com/1201090/
<roaksoax> allenap: or more complete:
<allenap> roaksoax: Yep. The release arg in the call to start_nodes isn't needed any more though.
<roaksoax> http://paste.ubuntu.com/1201093/
<roaksoax> allenap: http://paste.ubuntu.com/1201100/
<roaksoax> allenap: right, but start will reiceive the release to use from juju, and then it should say "the release for the node we are about to start is XYZ"
<roaksoax> which is what I'm trying to do
<allenap> roaksoax: I don't understand that.
<roaksoax> allenap: so juju will pass a request to maas
<roaksoax> which will contain the release to use for that partcular request
<roaksoax> then the start() method needs to set the release being passed to the node
<roaksoax> so that's why I need to get the node, set the correct release for that node
<allenap> Juju pseudo-does: acquire(some_constraints), start(user_data, os_release)
<allenap> Isn't that it?
<roaksoax> allenap: right, but a release won't be a constraint
<roaksoax> allenap: because a node can be used with X release or Y release
<roaksoax> allenap: we are treating this as an Instance approach
<allenap> I still don't understand why we need to set the release on the Node *and* pass it to start_nodes.
<roaksoax> allenap: we do *not* need to pass it to start_nodes
<roaksoax> allenap: we only need to set it for the node in question
<allenap> roaksoax: Ah, okay. Line 17 was passing it to start_nodes, wasn't it?
<allenap> In the earlier diff.
<allenap> Yeah.
<roaksoax> allenap: ah yeah, forgot to strip that out :)
<roaksoax> sorry :)
<allenap> No worries, I think we were going round in circles a bit there.
<allenap> Ah, right, start() accepts *optional* user_data and release. So, it can be used as just power control, but if those parameters are provided then it sets them before issuing a power-on (via start_nodes).
<allenap> So, the public-face of the API is actually okay. I don't think I have any concerns about that any more.
<allenap> Fwiw, passing the release in as a constraint isn't a crazy thing to do; some hardware may not be able to run some releases. For now I guess we can leave it as is.
<roaksoax> cool
<allenap> roaksoax: By the way, I'm going to start using commandant in trunk soon (so, Quantal only). I'm just bundling it in the source tree, but do you think you'll have time to package it? There is already a package at https://launchpad.net/~jkakar/+archive/commandant which can be used as a basic, and it's a very simple Python package.
<allenap> s/basic/basis/
<roaksoax> allenap: sure, can you remind me tomorrow ?
<allenap> roaksoax: I think you've already asked me to do that twice :)
<roaksoax> allenap: hehe yeah :) i added it to my todo
<allenap> Thanks.
<Daviey> allenap: do we need to package commandant ?
<Daviey> hah.. i see you are talking about it already
<Daviey> roaksoax: once you upload it, can you ping me for a NEW review please?
<roaksoax> Daviey: sure
<allenap> Daviey: Heh, nothing gets by you :) Thanks.
<Daviey> allenap: i just saw the MP :)
<roaksoax> yay support for ubuntu releaes work with juju tooo
<roaksoax> yaay
<Daviey> woot
<allenap> Does anyone know how to get into the Jenkins machine that runs maas's tests?
<allenap> Perhaps don't tell me in public though :)
#maas 2012-09-13
<melmoth> is rebooting a zookeeper node on a maas installation supposed to work ?
<melmoth> i did it on 2  sepearate installations, and after a reboot, the agent-state of the zookeeper node is being kept on "not-started" state
<lifeless> thats more a #juju question, sorry!
<lifeless> SpamapS: ^
<melmoth> zookeeper runs, but it s log does mention thing likes "xpiring session 0x139bcf841700004, timeout of 10000ms exceeded"
<SpamapS> as long as the address doesn't change, you should be able to reboot node 0
<SpamapS> agents should poll/reconnect eventually
<melmoth> thanks.
<smoser> roaksoax, around ?
<smoser> jtv, https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083
<smoser> roaksoax, ^ for you too.
<bigjools> smoser: I'll look
<bigjools> smoser: do you need something to uninstall all that when the package is removed?
<smoser> well ther ei sonly the one thing installed, and its will be removed just as any other file
<smoser> the one thing ... /etc/apparmor.d/dhcpd.d
<bigjools> smoser: ok - I didn't know if it was automatically removed or not
<bigjools> smoser: can you do a packaging.precise merge as well please
<smoser> yeah, its just a file.
<smoser> ackaging.precise will depend on sru of the isc-dhcp fix also.
<bigjools> yeah
<smoser> and i'd like to wait until this at least is baked a bit before uploading that.
<bigjools> yup
<smoser> tomorrow i'll try to do a pakaging merge for precise though and just have the mp ready
<bigjools> cool
<jtv> Thanks smoser!
<bigjools> hello jtv
<jtv> Hi
<jtv> bigjools: saw that email where DEFAULT_MAAS_URL turns out to tie into the UI somehow.  Damnation.
<bigjools> jtv: yes - I asked diogo exactly how it breaks
<bigjools> damnation indeed
<jtv> No idea where that happens.
<bigjools> back to the drawing board for you :)
<matsubara> bigjools, jtv: if I dpkg-reconfigure the package and choose 192.168.21.1 (the internal interface where pxe /provisioning runs) then the web server stops listening on 10.98.0.13
<jtv> Hi there matsubara
<matsubara> jtv, hey
<bigjools> hey matsubara
<jtv> Hmmm... this sounds as if the connection between UI and the setting is made in the packaging somewhere.
<bigjools> that's a bizarre thing for the web server to do
<bigjools> sounds like packaging
<jtv> Yup.
<jtv> It should definitely be listening on both interfaces.
<bigjools> not sure why we need to tell apache where to listen, all interfaces seems more reasonable to me
<jtv> Because it must service both you (the human) and the workers/nodes in the MAAS.
<bigjools> yeah
<matsubara> bigjools, jtv: when I run dpkg-reconfigure maas, it stops the apache server but doesn't restart it again
<bigjools> matsubara: haha!
<jtv> That does kind of explain...
<matsubara> in any case it looks like a bug, reconfigure should restart apache, shouldn't it?
<bigjools> yes
<bigjools> not sure why it needs to restart it at all
<matsubara> it stops it for some reason :-)
<bigjools> if you restart it, does the UIU and everything else work?
<bigjools> UI*
<jtv> I wonder where it stops apache...  it seems to be only the postinst and such that mess with apache.
<matsubara> yes, restarting it seems to bring the UI back up
<roaksoax> matsubara: there's a bug where reconfigure does not restart apache and I'll deal with that
<jtv> \o/
<bigjools> woo
 * bigjools heads out to lunch
<jtv> roaksoax: out of interest, where does it stop apache?  I would have expected to see that in maas.config.
<jtv> (Because I'm not a packaging expert)
<roaksoax> jtv: we don't stop apache2
<roaksoax> jtv: maybe it is crashing for some reason? the restart stops and start the daemon agian
<roaksoax> maybe that is it?
<jtv> Ohhhh
<roaksoax> jtv: no error logs?
<roaksoax> apache2 error logs that is
<jtv> Ask matsubara :)
<roaksoax> matsubara: http://paste.ubuntu.com/1201757/
<roaksoax> matsubara: try that
<jtv> I guess it's just a way to restart the wsgi processes..?
<roaksoax> matsubara: can you, however, directly point me to bugs or issues you find with packaging otherwise I'll lots in bugmail
<roaksoax> jtv: yes
<roaksoax> jtv: so dpkg-reconfigure maas, change IP should restart apache2 to pick the new IP and things should be just fine
<roaksoax> matsubara: ^^
<jtv> Wait... what new IP?
<jtv> Apache should be listening on all interfaces.
<jtv> MAAS must be aware of the new address, but not apache, right?
<roaksoax> jtv: yes, it is for maas to pick up the new IP
<roaksoax> and stuff
<matsubara> roaksoax, I'm looking at the apache logs. let me paste it for you
<roaksoax> jtv: the dpkg-reconfigure maas sets a new ip in DEFAULT_MAAS_URL
<roaksoax> s/in/for
<matsubara> roaksoax, https://pastebin.canonical.com/74380/
<roaksoax> matsubara: do you have a  node deployed where I can test?
<roaksoax> matsubara: err log in and test?
<roaksoax> that's maybe upstream error
<matsubara> roaksoax, the maas server is running but there's no node deployed
<roaksoax> matsubara: yeah can you tell me your steps to reproduce the issue you encountereD?
<matsubara> roaksoax, sudo dpkg-reconfigure maas
<matsubara> change the ip
<matsubara> the apache server is stopped but not restarted
<matsubara> feel free to log in the Lenovo lab
<matsubara> https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab
<roaksoax> matsubara: yeah that's a bug
<roaksoax> matsubara: there's a restart_apache2 missing on dpkg-reconfigure
<roaksoax> matsubara: http://paste.ubuntu.com/1201757/
<matsubara> I see
<roaksoax> matsubara: try now
<matsubara> is it a known bug?
<roaksoax> matsubara: yes it is a known bug, I will fix it tomorrow
<roaksoax> matsubara: i was concentrated on getting the releases support into maas
<roaksoax> matsubara: pastebin /etc/maas/maas_local_settings.py after the dpkg-reconfigure
<matsubara> roaksoax, yes, now it restarted fine
<roaksoax> matsubara: alright cool then
<matsubara> roaksoax, do you still need that pastebin?
<roaksoax> bigjools: btw.. if you can take a look at https://code.launchpad.net/~andreserl/maas/add_ubuntu_releases_lp1013146/+merge/124092 and tell me how is it looking, it would be great
<roaksoax> matsubara: nah!
<matsubara> cool. thanks
<roaksoax> matsubara: i'm sure the above fix has fixed things
<roaksoax> jtv: so can we ship our own maas-dhcp upstart job then?
<smoser> roaksoax, fwiw, there are python bindings to distro-info
<jtv> And hi smoser
<smoser> roaksoax, yeah you can do that.
<smoser> (i'm not really here)
<jtv> That explains.
<roaksoax> smoser: python-bindings as in import DistroINfo etc etc or similar?
<smoser> right
<jtv> roaksoax: I have a handy example of a modified upstart job if you want it.
<roaksoax> smoser: ah cool, willk use that intstead then
<roaksoax> jtv: sure, i wont merge it tonight though as I'm in zombie mode
<roaksoax> but will do tomorrow
<roaksoax> i'd like to get this fixed tomorrow
<jtv> @#$% timezones
<jtv> I'd be most grateful.  Hang on, I'll paste my upstart script.
<smoser> roaksoax, http://paste.ubuntu.com/1201799/
<smoser> thats a patch to cobbler that i used to use it there.
<smoser> might just get you started
<smoser> but its very simple
<roaksoax> smoser: nice, thanks!
<jtv> roaksoax: I named it maas-dhcp-server â http://paste.ubuntu.com/1201804/
<roaksoax> jtv: awesome, will merge it tomorrow and test
<jtv> Thanks!  We'll need to make corresponding changes to trunk as well, as we need to restart dhcpd.
<roaksoax> jtv: you can go ahead and make then later in your day today, so that tomorrow morning I can make the ones in packaging
<roaksoax> and we should be good
<jtv> \o/
<jtv> Thanks again.
<smoser> jtv, that looks reasonable.
<smoser> did you see my note that we will need packaging of that?
<smoser> as right now maas-dhcp just has 1 file
<roaksoax> smoser: i'll take care of that tomorrow morning :)
<jtv> smoser: If I'm thinking of the same note, then yes.  But that was quite some time ago now, so maybe there's something I'm missing.
<smoser> jtv, so how are you going to configure $INTERFACES ?
<jtv> /etc/default/maas-dhcp-server
<jtv> Which also needs packaging.
<smoser> jtv, no, my merge proposal had comment about it.
<jtv> Oh
<smoser> so you cant really do that
<jtv> Didn't see that.
<jtv> Why not?
<smoser> hm..
<smoser> so /etc/default/maas-dhcp-server is going to be a conf file
<smoser> and if you edit it
<smoser> and then the package upgrade
<smoser> it will force a prompt
<smoser> er... if the package'd file changes and there were local file changes.
<roaksoax> smoser: we need to handle that automatically i'm afraid
<jtv> Then... can we put it somewhere else?
<smoser> roaksoax, right. so /etc/default/maas-dhcp-server is not the right place.
<smoser> right.
<jtv> /var/lib/maas/dhcp-interfaces?
<smoser> for the things that you're configuring there, what i would suggest is some config not in /etc/
<roaksoax> smoser: i already have an idea of how to handle that automatically
<smoser> that maas managers
<smoser> but what you *could* do is have /etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces'
<smoser> or somethign like that.
<smoser> but having maas edit that file i think is not right.
<jtv> That's getting a little roundabout, given that all we want here is to set a variable.
<jtv> Why not just...
<jtv> if [ -f /var/lib/maas/dhcp-interfaces ]; then
<smoser> you can do that. but i'd not bother with 'dhcp-interfaces'.
<jtv>     INTERFACES=`cat /var/lib/maas/dhcp-interfaces`
<jtv> etc?
<smoser> but rather a shell sourceable file there.
<smoser> and then you can set other things in it there also
<smoser> rather than needing multiple settings potentially.
<jtv> Well then we can do one better: just add a management command that prints out the interfaces.
<smoser> thats what my suggestion above was
<smoser> (/etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces')
<jtv> Ah, then that'd be "maas" not "maas-shell," right?
<smoser> sure. whatever it was.
<smoser> or should be
<smoser> but yes, ask maas what the value is
<smoser> as it is the thing that knows
<roaksoax> smoser: that's a cool idea
<jtv> That's fine, yes.
<smoser> anyway
<smoser> bed time
<smoser> good night.
<jtv> nn
<bigjools> so why is apache only listening on the one interface?
<roaksoax> it is not, MAAS has as DEFAULT_MAAS_URL the IP of one interface
<roaksoax> as a best effort attempt
<roaksoax> to automatically determine what interface to be used
<bigjools> ok
<bigjools> to be used by what?
<roaksoax> s/interface/address
<roaksoax> to be used by MAAS as DEFAULT_MAAS_URL
<roaksoax> in packaging that is
<bigjools> I think we're confused about what it means
<bigjools> as far  as the code is concerned, it's the internal-facing URL for the nodes to contact for API
<roaksoax> bigjools: yep
<roaksoax> bigjools: i know that :)
<bigjools> ok :)
<bigjools> so we need to prompt for it on installation
<bigjools> it only does it on reconfigure
<bigjools> or is that deliberate?
<roaksoax> bigjools: that's deliberate. We cannot, should not prompt for it on installation
<bigjools> in any case it picks the wrong ip/interface in the qa lab
<bigjools> ok
<roaksoax> bigjools: that's why we display a message saying that if it is the wroing address it should be changed
<bigjools> gotcha
<bigjools> it's coming back to me now
<roaksoax> bigjools: if we always proimpt for it, it will break MAAS installation on the CD
<roaksoax> s/on/from
<bigjools> yeah
<roaksoax> alright
 * roaksoax is off to bed
<roaksoax> goognight all
<bigjools> nn
<jam> jelmer, mgz: https://plus.google.com/hangouts/_/6b0c81dbfeb8a772657f16370d380d1e26c9a4d3?authuser=0&hl=en-GB
<Daviey> roaksoax: not urgent today.. but can you explore using freeipmi-tools as a config option in maas upstream?
<roaksoax> Daviey you mean instead of ipmitool?
<Daviey> roaksoax: right
<mgz> hm, I can't make after updating trunk because buildout is timing out trying to get repl
<mgz> where do I need to remove it from to skip over that? it's not in versions.cfg and removing from buildout.cfg didn't help
<mgz> ah, need to edit the makefile
<smoser> roaksoax, do you happen to know why maas uses 'python-twisted'  as a dependency
<smoser> doku was asking me if that was necessary, versus a more fine grained list of what it actually uses.
<roaksoax> smoser pserv and txlongpoll need it
<smoser> but they dont need the blanket package
<smoser> they need specific things it depends on
<roaksoax> smoser why is that is it still uninstallable?
<smoser> are you asking whether or not it is uninstallable? or asking *why* it is
<smoser> i think doku probably fixed it, or if not is on it
<smoser> and it will be fixed
<smoser> but specifying a meta package when you dont need it is just wasteful
<smoser> (not a big deal, just we probably get things we dont need)
<roaksoax> python-twisted is a met package?
<roaksoax> smoser smoser: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/required-packages/base
<smoser> roaksoax, http://paste.ubuntu.com/1202679/
<smoser> it sure looks as "mostly meta"
<smoser> http://paste.ubuntu.com/1202680/
<smoser> roaksoax, its low priority
<smoser> but doku asked me
<smoser> as we wouldn't have seen the uninstallable if we didn't depend on that package :)
<smoser> rvba, around ?
<smoser> {{kernel_params(arch="amd64") | kernel_command}}
<smoser> what does that do ? in the templates
<smoser> is it "call kernel_params *or* use kernel_command ?)
<smoser> "
<roaksoax> smoser: hold on
<roaksoax> smoser: why was python-twisted uninstallable in the first place?
<roaksoax> smoser: cuase the reason why maas was uninstallable in your case was becuase a dependecy was uninstallable, not becuase it depended on a meta-package
<smoser> right.
<smoser> you are correct, roaksoax . python-twisted should never have become uninstallable (that was a valid issue) and prevented maas from being installed.
<smoser> but it just raised the question of "why were you depending on that meta package" rather than the specific packages you need
<roaksoax> smoser: now, we need to find out what dependencies of python-twisted are needed by maas
<roaksoax> allenap: ^^
<roaksoax> smoser: well upstream mentioned that as a dependes, maybe they just need python-twisted-core, or maybe just need the whole of python-twisted
<roaksoax> smoser: as pserv runs a twisted daemon
 * allenap looks
<allenap> smoser, roaksoax: python-twisted-{core,web} is all I think for direct deps.
<roaksoax> allenap: ok cool, i think we can update that then
<allenap> Cool.
<allenap> mgz: bzrlib.osutils.get_user_encoding() reports "ascii", but my args do seem to be encoded as utf-8. Would you happen to know if this is something my terminal has done, when I pasted in from charmap? Or a bug in get_user_encoding()?
<mgz> it's based on your C locale setting
<allenap> mgz: I'm tempted to use sys.getfilesystemencoding() but I'm not sure that's a good idea.
<allenap> mgz: en_GB.UTF-8
<allenap> LC_ALL
<mgz> okay, you probably are using bzrlib from a script but aren't calling `locale.setlocale(locale.LC_ALL, '')`
<allenap> mgz: Ah ha, such are the runes needed. Thanks.
<guimaluf> anyone can tell me what can be generating this error in my node syslog? Sep 12 17:34:26 150.164.3.160 main-menu[582]: (process:2659): wget: server returned error: HTTP/1.1 500 Internal Server Error
<guimaluf> Sep 12 17:34:26 150.164.3.160 main-menu[582]: WARNING **: Configuring 'network-preseed' failed with error code 1
<guimaluf> Sep 12 17:34:26 150.164.3.160 main-menu[582]: WARNING **: Menu item 'network-preseed' failed.
<mgz> guimaluf: are you filing bugs about the issues you run into?
<mgz> everyone: there's a really basic "what is maas" question on the openstack mailing list
<mgz> I'd reply if I knew how to give a pithy answer.
<guimaluf> mgz, no i'm not. I don't understand the cause of this issue. It happened out of nothing. :/
<mgz> guimaluf: if no one is around to answer on irc, it's good to follow up with either a bug report, or a message to the mailing list with more details
<mgz> people are in different timezones, there's no guarentee someone who can answer your questions will be on at the same time as you
<guimaluf> I know :/
<guimaluf> I'm trying to get information about my issue, but I dont know where to go :/
<mgz> so, hm, the launchpad MaaS page also suggests using askubuntu with the tag maas
<mgz> but when you've got a bug, I'd just file against maas on launchpad
<guimaluf> mgz, I found out the issue. the char 'Ã©' inside comments on maas.pressed :/
<melmoth> what does it mean when "juju deploy" on a maas server ends up with the new machine kept in "pending state" ?
<melmoth> on a working install, as soon as i deploy something, i see a new machine id, with info about it
<melmoth> but here, on the real cloud i try to install, the machine is still in pending, and no new machine are set into "allocated to root" on the web page
<guimaluf> melmoth, have you check the ssh-keys? in my case I'd give up to use maas + juju + openstack.
<guimaluf> cause of this. all my servers kept in pending state.
<melmoth> yep, not the ssh key.. turned out zookeeper was having problem, did not investigate , we are on our way to a new bootstrap
<guimaluf> melmoth, exactly! zookeeper problem!
<guimaluf> anyone know how can I set up a smarter partition scheme when deploying a node? I've tried late-command, but isn't working. :/
<melmoth> guimaluf, http://pastebin.com/gtxGJgt3
<melmoth> this is a preseed i used on a 1 disk machine where i wanted to have a nova-volumes vg separate from the vg used by the system done at installation stage
<melmoth> i guess doing something similar in the preseed file used by maas should work (but you dont have to bother creating the nova-volumes vg, the nova-volumes charms takes care of it)
<guimaluf> melmoth, partman can only handle with one disk. I want to make sd[b-z] also avaible
<melmoth> havent try with several disk, my main problem was that i had only 1 anyway :)
<guimaluf> I had, and partman dont deal with more then one disk. also none of my recipes had been aplied
<melmoth> grumble same stuff again
<melmoth> ahhh, note for later: dont put 127.0.0.1 for the maas server in the juju environment.yaml :)
<melmoth> things seems better now
#maas 2012-09-14
<smoser> jtv, do we have dhcpd fixes in?
<bigjools> he won't be around for another hour
<smoser> ppa seems uninstallable for me
<smoser> bigjools, http://paste.ubuntu.com/1203854/
<smoser> that is from daily ppa
<bigjools> darn it
<bigjools> smoser: a change was made in the code that now needs a packaging change I think, I'll dig
<bigjools> yeah postinst call
<smoser> right.
<bigjools> not sure why it was removed in the 1.1 branch :/
<bigjools> I'll do a branch to fix it
<smoser> bigjools, it seems like it is more than just '--dhcp-interfaces' -> '--interface' (which also seems like potentially a deeper issue because the debconf question is asking for plural and this seems to expect singular)
<bigjools> smoser: yes we're making 1.1 only manage one interface
<bigjools> trunk supports multiple
<smoser> http://paste.ubuntu.com/1203878/
<smoser> after fixing the simple --interface, that is the command that the postinst runs and fails as shown
<bigjools> oh ffs
<bigjools> someone has backported too much
<smoser> this is daily ppa of trunk
<bigjools> oh ok
<bigjools> I think a data migration is needed
<smoser> bigjools, do you happen to have a reason for 'suite=' on the kernel cmdline ?
<bigjools> I'll file a bug
<bigjools> smoser: I doubt it - most of those were cargo culted from cobbler
<smoser> k. i'm dropping it.
<bigjools> feel free to fix as you see fit
<smoser> https://code.launchpad.net/~smoser/maas/kernel-cmdline-cleanup/+merge/124226
<smoser> i haven't fixed tests yet, but the kernel cmdline is much cleaner now
<bigjools> I'll review it shortly, just putting up the packaging fixes
<smoser> the tests wont pass
<bigjools> ok, do you need help with those?
<bigjools> smoser: https://code.launchpad.net/~julian-edwards/maas/packaging.precise/+merge/124328
<bigjools> ARGH
<bigjools> wait
<smoser> i'll take help with them. sure. as i was hoping to get out of here.
<bigjools> so if you ignore the rules change everything else is ok in that branch :)
<smoser> my description is hopefully fairly complete in describing what i dropped.
<bigjools> just pushed up a fix
<bigjools> ok
<bigjools> if you check my packaging change I'll try to fix tests
<bigjools> in yours
<smoser> bigjools, well, i dont think your pakcaging change does fix it
<smoser> as that pastebin above
<smoser> i basically made that change locally and hten hit a python trace
<bigjools> smoser: it will fix packaging
<bigjools> a separate change is needed upstream
<bigjools> because it's assume some data is present, which is not there
<smoser> ah. well packaging still wont install :)
<bigjools> one thing at a time :)
<smoser> bigjools, i can ACK that packaging change.
<bigjools> thanks
<smoser> per removal of rule schange fix.
<bigjools> yeah - it's changing to lp:maas/12.04-nocobbler
<bigjools> as it was wrong in the target branch anyway
<bigjools> diff has updated now
<smoser> you could make that a variable
<smoser> when you want to fix it
<smoser> ./debian/rules BZR_BRANCH=lp:maas/12.04-nocobbler
<smoser> approved.
<bigjools> thanks
<smoser> i'm gonna head out for the night.
<bigjools> I'll poke it in trunk packaging too
<bigjools> cheers
<bigjools> sleep well
<smoser> lp:~smoser/maas/maas-pkg-test
<smoser> thats mostly just junk, but its what i'm working on as a setup/test for the packaged stuff.
<bigjools> cool
<smoser> it allows me to get to booting and enlisting (assuming non-broken packaging)
<smoser> and it has to be kept up.
<smoser> but its a start.
<bigjools> yep
<jtv> smoser: no dhcpd fixes yet to my knowledge.  Needs the packaging changes first, in both quantal and precise.
<jtv> I am writing that command that gives you a cluster's managed DHCP interfaces though.
<bigjools> morning jtv
<jtv> Hi
 * jtv cries at the sight of his reviews
<bigjools> :)
<bigjools> I am looking at the long one but dunno how much I can review
<bigjools> conflicts FTL
<bigjools> hmm just one stray marker
<bigjools> weird
<bigjools> unless you messed up a merge and forgot to remove it
<jtv> Which one is that?
<bigjools> https://code.launchpad.net/~jtv/maas/bug-1025582-task/+merge/123900
<ubot5> Ubuntu bug 123900 in SchoolTool "Better Zonki" [Wishlist,Fix released]
<bigjools> ubot5: you suck
<jtv> I never had any conflicts on that one.  I think it's just weirdness with the way conflicts propagate through dependent branches.
<jtv> I resolved my conflicts on the -api branch.  Will propagate the resolutions through the dependent branches.
<roaksoax> howdy
<roaksoax> bigjools: so 'maas config_master_dhcp' enables MAAS DHCP server if not enabled right?
<roaksoax> bigjools: is it possible to add a command that disables it?
<bigjools> roaksoax: it does
<roaksoax> such as maas disable_master_dhcp
<bigjools> anything's possible :)
<bigjools> why do you need it?
<roaksoax> bigjools: so thatn when maas-dhcp gets uninstalled, or dpkg-reocnfigure and set to NO, it gets disabled in MAAS
<bigjools> fair enough
<roaksoax> bigjools: btw.. short response to the email on adding releases support
<roaksoax> bigjools: most of what scott discussed is already addressed
<roaksoax> bigjools: and the support has been added
<roaksoax> bigjools: https://code.launchpad.net/~andreserl/maas/add_ubuntu_releases_lp1013146
<bigjools> roaksoax: yeah I figured you guys were working on it
<roaksoax> bigjools: i also have the juju stuff worked out, and tested
<roaksoax> bigjools: the only thing needed is modify the maas unnittests
<bigjools> ok
<roaksoax> ok cool
<roaksoax> it should be proposed next week though
<roaksoax> i need to updated and resolve conflicts with the new trunk
<bigjools> roaksoax: I don't like the magic enum, FWIW
<roaksoax> bigjools: yeah i need to change that
<bigjools> it means restarting maas for a new release
<bigjools> release should be a DB table
<bigjools> then we can add pickers for it later
<roaksoax> bigjools: you bean enum UBUNTU_RELEASES?
<bigjools> also a customer might have a custom release
<bigjools> yeah
<roaksoax> bigjools: well I think we should rely on distro info for that
<roaksoax> bigjools: that's the accurate way to obtain the ubuntu supported releases
<bigjools> why should someone be restricted to deploying ubuntu supported releases?
<roaksoax> bigjools: and wouldn;t mean harcodign releases, and SRU'ing new changes on and on
<bigjools> I am proposing to make it data-driven
<roaksoax> bigjools: well that means that every time there's a new release, we have to SRU
<roaksoax> which is a clear PITA
<roaksoax> bigjools: this was an issue we had in cobbler
<bigjools> No, we don't :)
<bigjools> I think what you have is ok short term, because it will need a lot of changes in the UI to do what I propose
<bigjools> if it's data driven we can add new releases in the UI
<roaksoax> bigjools: right sounds fair
<roaksoax> bigjools: i will get that to trunk first
<roaksoax> bigjools: and we can go from there
<roaksoax> as it is currently blocking me on other stuff until there's no real quantal support in
<bigjools> roaksoax: yeah
<roaksoax> alright then.
<bigjools> roaksoax: oh also we *might* want to call it series, not release
<bigjools> to be consistent with Launchpad
<roaksoax> bigjools: yeah that's one of the changes I need to make
<bigjools> release was intended to be point releases
<bigjools> ah cool
<roaksoax> bigjools: What's your preference? series, ubuntu_series or os_series
<bigjools> distro_series
<roaksoax> ok cool
<bigjools> thanks!
<bigjools> roaksoax: let us know if you want help with tests
<roaksoax> bigjools: yep, rvba already offered himself :)
<bigjools> cool
<bigjools> jtv: done
<bigjools> and now I shall eat luncheon
<jtv> Thanks!
<jtv> I'll be going to mine too.
<bigjools> mine will involve biking over Mount CootTha though
<jtv> AAAAArgh.  Semantic conflict with RaphaÃ«l's changes.
<jtv> *bash* *bash* *bash*
<jtv> Three days of begging for a review, and when I finally get one, my code is obsolete.
<jam> disconnected ... :(
<jtv> Very.
<jam> jelmer: would you like to come back on mumble?
<jelmer> jam: yep
<jam> jelmer, mgz: poke when you get back. I have to go in about 15 min.
<smoser> hey
<smoser> whats the simplest way to be albe to run unit tests ?
<smoser> i'm assuming that 'make install-dependencies' will get me stuff, but i dont think i need all that.
<smoser> jtv,rvba?
<jtv> Hi there
<rvba> Hi smoser.
<smoser> sorry for direct ping.
<jtv> Try "make test".
<smoser> well, fails: Error: pg_config executable not found.
<jtv> Then have you tried "make install-dependencies"?  :)
<smoser> well i said that is plain silly.
<smoser> i just want to run tests.
<jtv> Have a look in required-packages.
<rvba> smoser: maybe you're missing the package 'libpq-dev'.
<jtv> I think the make target gives you the "base" and the "dev" ones, not the "optional" ones.
<smoser> rvba, well clearly i am.
<smoser> and i can peicemeal get the stuff.
<smoser> but 'make install-dependencies' gets all sorts of things that surely are not necessary for 'make test'
<smoser> i just want to run unit tests
<smoser> (so maybe maketest is too broad anyway)
<jtv> Yes, there's a bunch of stuff in "base" that should be in a separate list.
<jtv> But the fact is we just haven't gotten around to breaking that down any further.
<smoser> k.
<smoser> thats a fine answer.
<jtv> Thank you.
<smoser> so basically you'll just 'make install-dependencies' ?
<smoser> jtv, i'm assuming you thought i was being sarcastic :) but this time i actually wasnt.
<jtv> Or do it piecemeal, as you say; I think the stuff in dev is all needed at least.
<smoser> i just wanted to know if i was doing something stupid.
<jtv> No worries!
<smoser> so on your system youve just got the whole shebang
<smoser> thats fine. the schroot buildup was just going for a couple minutes before i got bored with it.
<smoser> so do we think that the daily ppa is installable now?
<jtv> I think for testing you should be able to do without bind9, probably bind9utils & dnsutils & isc-hdcp-common, ipmitool (I hope!), and maybe syslinux-common.  And you can probably do without wget.
<jtv> I haven't looked at the python-* packages in detail; I expect you'd need most or all.
<guimaluf> anyone know how can I set up a smarter partition scheme when deploying a node? Partman can only handle one partition, so I've tried late-command, but isn't working. :/ any hint?
<jtv> No idea how you'd tell the installer that.  :/
<smoser> guimaluf, well, you probably want partman_early_command
<smoser> late_command is (no surprise) too late.
<smoser> i'm fairly sure you can preseed just about whatever you want as a partition layout, but i really havent ever played with it.
<smoser> http://bryars.eu/2011/08/automating-debian-preseed-installs-with-raid-and-lvm/
<smoser> seems reasonable a s a starting point
<smoser> jtv, is 'make test's install of dependencies direcotory specifi c ?
<smoser> ie, if i hvae trunk.my-feature and trunk-my-fix dirs, do i need one for each or are they somehow shared
<jtv> "make test" doesn't install anything.
<smoser> well, its dependencies do
<jtv> It may run buildout, which may be set up to share a cache across branches.
<smoser> s/install/buildout/
<smoser> for being technical
<smoser> k
<jtv> Ah.  Then the answer is: I think it depends on your local setup.
<guimaluf> smoser, I've tried many recipes and use multiple disks(I said wrong, partman can only handle one DISK), none of this worked for me :/ I dont know why... my solution was using guided lvm installation with 15% of disk space. It's working fine, but I want to partitionate the other 3 disks.
<guimaluf> smoser, I'll try to use this early command
<smoser> guimaluf, well this is n't really maas specific.
<smoser> and as i said, i've never really done this.
<smoser> but i do believe it shoudl be possible
<guimaluf> smoser, I know it's not related directly with maas, but it's a customization I want to use with maas.
<smoser> understood.
<smoser> ok. i have a python quesiton
<mgz> nooooo....
<smoser> KernelParametersBase is a named tuple
<smoser> but how do values for each key get set?
<mgz> construct it with args/kwargs
<smoser> at least i see code expecting 'params.purpose' to have some value, but i dont understand where it gets said value.
<smoser> ok. got it.
<mgz> eg, I see in tftp: `KernelParameters(**data)`
<mgz> and also by defined names in maasserver.api
<mgz> smoser: a question in return, constraining by arch -
<mgz> currently juju/ec2 allows 'i386' and 'amd64' which must match exactly, or '?' to mean either
<mgz> as you can stick an i386 image on a amd64 box to satisfy the contraint, what should maas do when told to acquire an i386 machine?
<mgz> there's no way of picking images currently, right?
<smoser> there is no way of picking images, no.
<smoser> well, as what hsould maas do... it should install i386
<smoser> thats easy!
<smoser> as to whether or not it can, i dont know.
<smoser> was that the question, mgz?
<mgz> so, Node has an architecture param right now, and I added a constraint to just match that,
<mgz> see <https://code.launchpad.net/~gz/maas/arch_constraint/+merge/123789>
<mgz> I should special case accept both 'amd64' and 'i386' there, and add some logic to pick the right image?
<mgz> or just accept that this is overly limiting for now, till we have some image fanciness?
<smoser> i think near term there are no images.
<mgz> so near term, if a node says it's amd64, it really is going to end up 64 bit?
<smoser> i think i agree with what you're saying. basically if i386 comes in as a constraint, or it is otherwise told to install i386 that it should just allow it if the node is amd64
<smoser> mgz, this is not un-related to the "multiple release" issue
<smoser> we had the same problem there, really.
<smoser> there is just a global "release"
<smoser> and we're now attachign that as an attribute of the node
<mgz> right, that is similar.
<smoser> but really we want an "instance" ("deployment" or whatever) table
<smoser> and that instance/deployment would say "i386" is the arch
<smoser> but we dont have that now.
<smoser> and if you change the node's arch for a deploy, then you have to store the *real* arch to avoid downcasting permenantly.
<smoser> ie, for release we just said that Node.os_release would just be set back to None on 'release'
<smoser> what are the values acceptable for "purpose" of KernelParameters ?
<smoser> the only code i see looks for 'commissioning'. so thats the only string i ssee that is seemingly valid.
<mgz> probably that's all that's defined as having a meaning right now
<smoser> mgz, did you follow what i was saying above?
<smoser> its reasonable that you could accept that constraint.
<smoser> but if someone asks for i386, you shoud'nt give them amd64 and just pretend you did what they asked.
<smoser> the use case for i386 on amd64 is very slim, and honestly i386 in general. but i tihnk maas should install an i386 distro if its asked to do so.
<mgz> right, until we can actually stick an appropriate image on the machine, the current constraint is correct
<smoser> but to do that you ahve to change the arch of that node
<smoser> and then you have to store what it *really* was so you can put it back later.
<jtv> smoser: any luck getting the dhcpd apparmor profile into precise and quantal?
<smoser> jtv, its in quantal
<smoser> it wont be in precise until it works for you in quantal
<jtv> !
<smoser> i'm not SRUing anything that isn't known functional
<smoser> (that is a SRU requirement)
<smoser> that it is fixed in the development release, and i personally dont consider "fixed but not verified as useful" the same thing as "fixed released"
<jtv> At least now I can move ahead with the quantal side I guess.
<smoser> correct
<smoser> oh. hey. one question, jtv
<smoser> how do you kick a build of daily ppa ?
<smoser> its out of date
<smoser> (and uninstallable)
<jtv> Isn't a daily PPA supposed to build daily?  In which case, the trick would be to find out what's been stopping it from building.
<smoser> yeah i would have thought hte same
<smoser> but afaiks https://launchpad.net/~maas-maintainers/+archive/dailybuilds?field.series_filter=quantal is revno 987 but https://code.launchpad.net/~maas-maintainers/maas/trunk is at 1000
<jtv> My guess is that pushing a "build again" button probably wouldn't do much good, if the build doesn't come through.
<jtv> smoser: Hmm... I see a 20-hour-old package at 994.
<jtv> Isn't that the one you want?
<jtv> Ah, it's not built
<smoser> ok. i'm blind. where do you see this?
<smoser> i see 0.1+bzr987+dfsg-0+994+83~ppa0~quantal1
<smoser> gay
<smoser> never mind
<smoser> :)
<smoser> i have no idea what i saw at 987
<smoser> oh. as you said, the newer isnt built
<smoser> i'm really confused
<jtv> So am I.
<jtv> No idea what the 994 stands for.
<jtv> I need to run out for a bit.
<roaksoax> 994 is bzr branch
<roaksoax> 987 is the bzr branch on the packaging branch
<roaksoax> and 994 is the branch the daily build is creating
<roaksoax> i mean, [packaging
<jtv> Thanks!  Problem solved then, I hope.
<smoser> roaksoax, ok. can i get a new trunk ?
<smoser> a build of new trunk
<smoser> i want 0.1+bzr1000
<roaksoax> smoser: you want one released today?
<roaksoax> smoser: or someone can just fire up a new daily build
<smoser> roaksoax, i'm sorry for being confusing.
<smoser> i want the daily ppa to have the latest trunk
<smoser> (and i think generally i always want that.... no?)
<roaksoax> smoser: so someone needs to fire up a new build then
<roaksoax> smoser: 0.1+bzr987+dfsg-0+1000+83~ppa0~quantal1
<roaksoax> that's what you want
<smoser> so bzr987 is the packaging version?
<smoser> but anyway, yes. thats what i want.
<smoser> and generally if we can have per-commit, that'd be good too.
<smoser> i think
<smoser> at least it would seem.
<smoser> jtv, what is the correct style for this: http://paste.ubuntu.com/1204901/
<smoser> specifically i'm asking about the line 8 and the replacement of that method (get_ephemeral_name)
<smoser> (lines 93-106)
<smoser> rvba, ^ ?
<rvba> smoser: use patch(), let me give you an exampleâ¦
<smoser> i see it.
<smoser> thanks
<rvba> smoser: ok, cool.
<smoser> rvba, ok. now i ask for review.
<smoser> https://code.launchpad.net/~smoser/maas/kernel-cmdline-cleanup/+merge/124226
<rvba> smoser: ok, I'm finishing up a branch and then I'll review it.
<fjlacoste> smoser: daily builds builds _daily_
<fjlacoste> buildd resources are scarce :-)
<smoser> fjlacoste, can you poke it manually?
<smoser> (just curious)
<fjlacoste> smoser: yes
<fjlacoste> smoser: you can always push a button to build now
<fjlacoste> there is probably an api to request it
<fjlacoste> (i'm really speculating here)
<fjlacoste> so we could automate it (as a post-jenkins action)
<smoser> where is the button?
 * smoser sucks with web uis
<smoser> fjlacoste, ^
<flacoste> smoser: it's not you, it's LP :-)
<flacoste> smoser: the button is on the recipe page
<flacoste> which isn't obviously linked from the archive page
<flacoste> i got to it from the package details
<flacoste> expand a build
<flacoste> then click on the recipe build
<flacoste> very very obvious :-)
<flacoste> here's the link:
<flacoste> https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-precise
<flacoste> there is a Request a build link at the bottom
<flacoste> which asks for which series to build to
<flacoste> precise is building now
<flacoste> i'll ask quantal
<smoser> thanks.
<smoser> flacoste, would you be upset if i linkd that from the daily build ppa description?
<flacoste> smoser: not at all, users always find a way ;-)
<smoser> done
<smoser> thank you.
<smoser> BAH
<smoser> https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/306950
<smoser> strange. seems to have uploaded though anywah
<smoser> fudge. still uninstallable
<smoser> roaksoax, http://paste.ubuntu.com/1205032/
<roaksoax> smoser: that's becuase dhcp now needs you to specify IP and it hasn't yet been done
<roaksoax> smoser: rvba just pointed it out to me today so I haven't done that just yet
<roaksoax> if you want you can go ahead and fix it though :)
<jtv> smoser: meanwhile, I think we have to shelve this idea of the dhcpd upstart script getting its interfaces list from the maas database.  Not the rest, so we still need to run our own dhcpd, but since there's no database locally, we might as well just store this information in /var/lib and have the upstart script read directly from that.
<jtv> (Contacting the API at that point in bootstrapping would be difficult)
<jtv> Now, where is that directory where I can put my apparmor config snippets for dhcpd?
<smoser> jtv, thats fine.
<smoser> jtv, the packaging already lays one down
<smoser> https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083
<smoser> also see examplecommand line there
<jtv> Thanks smoser â I don't see the example command though.  I see it's a different approach from the include-a-directory one we discussedâ¦ how do we get apparmor to apply our profile to dhcpd?  Link the executable?
<rvba> smoser: branch approved with a few remarks.
<smoser> jtv, well, there could be a bug in the packaging... i'm not exactly sure how it gets updated. but you should not worry about that.
<jtv> Okay, I'll try not to.
<smoser> jtv, command line example is in comment 0 https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083/comments/267072
<jtv> Ah
<jtv> Too tired.
<smoser> roaksoax, https://code.launchpad.net/~smoser/maas/packaging.aa-update/+merge/124478
<smoser> jtv, ^ that has the fix to apply the apparmor profile on maas installation/upgrade
<roaksoax> smoser: approved
<smoser> roaksoax, are you working on the ipaddr fix ?
<roaksoax> smoser: nope
<roaksoax> plop
<roaksoax> rvba is gone
<roaksoax> and i just finished the release stuff
<smoser> oh. good.
<smoser> can i see ?
<roaksoax> smoser: https://code.launchpad.net/~andreserl/maas/add_distro_series_support_lp1013146/+merge/124482
<roaksoax> smoser: and this is for juju: http://paste.ubuntu.com/1205229/
<smoser> why do you use the word series?
<roaksoax> smoser: bigjools requested so
<smoser> then maybe change KernelParameters release=
<smoser> dont you think its just confusing to insert inconsistency of a string inside the code?
<roaksoax> smoser: yeah I'll do that too after this stuff gets merged because tests will have to get changed, and there's plety of tests to fix with this MP
<roaksoax> smoser: yes it is confusing, but bigjools says it matches LP code when referring to a release.
<smoser> line 10
<smoser> you are adding a commissionoing_distro_series to the node, right?
<smoser> oh i see. you're not. lever mind then.
<roaksoax> smoser: no
<roaksoax> smoser: that's just saying if there's no node or the node is commissioning, the present the series for commissioning
<roaksoax> that's for the kernel parameters
<smoser> right
<smoser> i thought you were setting a field on the node but only referencing the global default
<smoser> but you're not setting the field on the node.
<smoser> so thats fine.
<roaksoax> smoser: yes, we are not, when we set the node is on juju http://paste.ubuntu.com/1205229/
<smoser> roaksoax, how do i build package from daily ppa ?
<roaksoax> smoser: i don't know TBH... julian set that up
<smoser> hmm. well 'bzr bd -S' just fails for me.
<Daviey> smoser: https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-precise/+request-builds
<smoser> Daviey, yeah, thats fine. i wanted to build locally
<Daviey> ok
<smoser> its not extracting the upstream tarball at all.
<smoser> matsubara, around?
<smoser> i tihkn i have it back into place now.
<smoser> matsubara, had added a file in the debian branch (tests/integration.py directly) rather than as a debian/patches and debuild complained due to
<smoser> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I --source-option=--abort-on-upstream-changes"
<matsubara> smoser, hi, yes
<smoser> see above.
<smoser> https://code.launchpad.net/~smoser/maas/packaging.next-server/+merge/124493
<smoser> its fixed in that merge propposal there.
<matsubara> smoser, jibel suggested that I should add tests/ at the root of the packaging branch rather than debian/tests/
<matsubara> smoser, that's for the autopkgtest work.
<smoser> matsubara, hm.. well, i'm not sure.
<matsubara> smoser, hmm those tests don't modify any upstream files...
<smoser> but i dont think its right (and debuild complained to me) to lay down that file from the debian overlay.
<smoser> it modifies a file (creates it) outside of debian/
<smoser> which its not supposed to do
<matsubara> ah, I see
<smoser> i honestly dont know about autopkgtest though
<matsubara> I'll ask jibel about it then. the thing about leaving it as a patch is that I think autopkgtest might ignore it
<smoser> i'm sure somehow those 2 things have been resolved if others are doing this.
<smoser> nah.
<smoser> i woudl doubt it
<smoser> the first thing that dpkg does is apply patches when it extracts source.
<smoser> so unlikely that the autopkgtest would operate before that
<smoser> roaksoax, does something magically pull the approved branchesinto  packaging branch ?
<smoser> or do i have to do that manually?
<roaksoax> smoser: the lander does it
<roaksoax> smoser: did you add the commit message?
<smoser> yeah
<smoser> just di
<smoser> d
<matsubara> smoser, cool. your mp should be fine then. I'll talk to jibel on monday and see if there's a standard
<matsubara> and then do any modificaton that's needed
<smoser> matsubara, thanks.
<smoser> and roaksoax it seems like it just got landed
<smoser> roaksoax, https://code.launchpad.net/~smoser/maas/packaging.next-server/+merge/124493
<smoser> now review that please
<smoser> :)
<smoser> we're almost installable!
<smoser> wweeeee!
<roaksoax> smoser: why is there a patch for add-maas-ingration.py
<smoser> see above.
<smoser> you're not supposed to write files outside of debian/
<smoser> dpkg --source-option=--abort-on-upstream-changes complains about that.
<roaksoax> oh i see
<smoser> so once the lander lands that i'll push the "build" button and i think we might have it installable
<Daviey> \o/
<roaksoax> arrgh I have one more test to fix in juju and we should be deploying series with juju too
<smoser> shoot
<smoser> https://launchpadlibrarian.net/115990138/buildlog.txt.gz
<smoser> anyone have ideas on that?
<roaksoax> nope
<roaksoax> :/
<smoser> i kind of hope it is as simple as my stupid patch name
<smoser> (ended in .py)
<smoser> but i'm trying to build the recipe now and see if i can make it fail here and then succeed
<matsubara> roaksoax, I'm trying to build a package from the precise branch: https://code.launchpad.net/~matsubara/+archive/maas/+packages but it doesn't build python-django-maas. Is there anything special I need to do in the recipe?
<roaksoax> matsubara: nope, the like above hasn't yet built precise though
<matsubara> roaksoax, ah, it takes a while to build all the packages? just the maas is published first?
<roaksoax> matsubara: when you upload to PPA it is all related to the score
<roaksoax> matsubara: so it has to build the mpackage and then it will publish the biinaries
<roaksoax> matsubara: look at build status
<roaksoax> https://code.launchpad.net/~matsubara/+archive/maas/+build/3787754
<matsubara> I see
<matsubara> thanks
<roaksoax> no prob :)_
<smoser> roaksoax, https://code.launchpad.net/~smoser/maas/rename-patch/+merge/124506
<smoser> please.
<smoser> matsubara, it seems i screwed up
<smoser> please review the above
<smoser> it sucks. we can try to find a better fix later, per jelmer its a bug in the builder
<matsubara> smoser, looks good, isn't going to fail to build because of the file in outside the debian dir? or is it just a warning?
<smoser> that was only reproducable locally
<smoser> but the other way was only reproducible on the server
<smoser> :-(
<smoser> at least i tihnk. but it could have been user error.
<smoser> anyway, it *did* build the way you had it. so i  hope it will again.
<matsubara> :-)
<smoser> push 'approve' ?
 * roaksoax lunch
<smoser> ok. one more time i abuse the builder
<smoser> hopefully this time it works.
<smoser> https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/307137
<smoser> ok. so it built. YEAH!
<smoser> https://launchpadlibrarian.net/115995593/buildlog.txt.gz
<smoser> k. matsubara roaksoax the daily ppa is installable and built
<smoser> but it doesn't seem to register boot files
<smoser> i see a message about 'No boot images have been registered yet"
<smoser> its possible i have to wait 5 minutes (it says i might) but if thats the case, that is broken
<smoser> (broken as in, test is going to need to say "how about you do that NOW and block until its done")
<smoser> jtv, if you see the above, i think that was code you recently committed.
<roaksoax> awesome
<roaksoax> smoser: thanks for making it build
<matsubara> smoser, I'll give it a try later on. I need to step off to eat
<smoser> yeah, so still see the "no boot images" message
<smoser> after 32 minutes.
<smoser> http://paste.ubuntu.com/1205716/ is celery.log
<smoser> lp:~smoser/maas/maas-pkg-test/ is what i have done
<smoser> to get this far
#maas 2012-09-15
<jtv1> smoser: that's a change I landed the other day, yes.  Is there a problem with it?
<smoser> jtv, see the pastebin http://paste.ubuntu.com/1205716/ . basically it seems that the ui never thinks it is ready, and worse, i can't seem to pxe boot (even though the files are in place).
#maas 2012-09-16
<jtv> smoser: looks like I neglected to register the report_boot_images task.  The inability to pxe-boot should be entirely unrelated.
<jtv> Or wait, I think that path is simply wrong...
<smoser> jtv, opened bug 1051626
<ubot5> Launchpad bug 1051626 in MAAS "tftp import broken" [Critical,Confirmed] https://launchpad.net/bugs/1051626
<smoser> your fix seems not complete in my testing.
<jtv> smoser: I commented on the bug.  The fact that the error is still displayed may be unrelated to the remaining pxeboot problem.
<lifeless> morning
#maas 2013-09-09
<AskUbuntu> Juju - Installing ceph and ceph-osd charms on same machine? | http://askubuntu.com/q/343349
<kentb> probably been asked a million times, but, when will 1.2+bzr1373+dfsg-0ubuntu1~12.04.2 come out of proposed for 12.04?
<allenap> roaksoax: The fix for https://bugs.launchpad.net/maas/+bug/1204507 (empty files) doesn't seem to be available for Precise. Do you know if there's an SRU in progress for it?
<ubot5> Launchpad bug 1204507 in maas (Ubuntu Quantal) "MAAS rejects empty files" [Undecided,Confirmed]
<roaksoax> allenap: https://launchpad.net/ubuntu/+source/maas/1.2+bzr1373+dfsg-0ubuntu1~12.04.2
<allenap> roaksoax: The empty files fix was in r1378, but that indicates that it's only 1373. Have I misunderstood?
<allenap> In lp:maas/1.2
<roaksoax> allenap:  Merged into lp:maas/1.2 at revision 1378
<roaksoax> allenap: yeah that's right
<allenap> roaksoax: I have to go, but I'll be back in ~2h, and I'll catch up with you then.
<roaksoax> but we don't sru new branch release
<roaksoax> we cherry pick
<roaksoax> and SRU patches
<roaksoax> 99_filestorage_empty_files_lp1204507.patch: Fix to allow the storage of empty files when using Juju Go, otherwise machines will fail to bootstrap. (LP: #1204507)
<ubot5> Launchpad bug 1204507 in maas (Ubuntu Quantal) "MAAS rejects empty files" [Undecided,Confirmed] https://launchpad.net/bugs/1204507
<allenap> roaksoax: What does the bzr1373 in the package version refer to?
<roaksoax> allenap: that;'s the released version of maas in precise
<allenap> roaksoax: Does that refer to a branch revision anywhere?
<roaksoax> allenap: yes, that's the branch revision of maas 1.2
<roaksoax> allenap: that's what was  in raring at a certain point that got backported into preciuse/quantal
<allenap> roaksoax: Right, so in Precise is 1.2 at r1373 plus some patches?
<roaksoax> allenap: yep
<roaksoax> allenap: so precise is 1.2 r1373 + all the bugfixes that had been SRU'd
<allenap> roaksoax: Okay, thanks for that.
 * allenap really goes.
<kentb> roaksoax: so when will r1373 go from -proposed to into -updates?
<roaksoax> kentb: when someone other than me verifies that all the fixes are ok and cause no regressions
<kentb> roaksoax: got it :) hasn't regressed anything for me (yet) if that counts for something.  I can update the bug report at least with what I was able to observe.
<roaksoax> 2013-09-09 14:04:35.328307 7f6b93088700 -1 monclient(hunting): ERROR: missing keyring, cannot use cephx for authentication
<roaksoax> 2013-09-09 14:04:35.328607 7f6b93088700  0 librados: client.admin initialization error (2) No such file or directory
<roaksoax> Error connecting to cluster: ObjectNotFound
#maas 2013-09-10
<bigjools> roaksoax: around?
<roaksoax> bigjools: momentarily
<roaksoax> bigjools: what's up
<bigjools> roaksoax: I need to talk about chassis ilo but it might take longer than you have
<roaksoax> bigjools: well i just came back from running so i'll go take a shower and come back
<bigjools> roaksoax: okidoki
<roaksoax> bigjools: here
<bigjools> roaksoax: right
<roaksoax> bigjools: so what's up
<bigjools> roaksoax: see internal irc
<roaksoax> bigjools: I think we need to allow maas to manage DHCP for different interfaces
<kurt_> roaksoax: does it already?
<kurt_> s/does/doesn't
<roaksoax> kurt_: not it precise at least
<kurt_> roaksoax: ok, I thought it did.  If it doesn't it should. :)
<roaksoax> kurt_: yeah I thought so too but just came accross an error. Maybe that's fixed in trunk but not in precise
<kurt_> roaksoax: has juju 1.13.3 been tested against maas on precise yet?
<roaksoax> kurt_: i think it has... I wouldn't know TBH
<kurt_> ok
<bigjools> roaksoax: we only manage one interface on a CC
<bigjools> it is an outstanding feature request to do more than one
<bigjools> smoser: is the output of the pack_install() call a binary blob?  ie do I need to base64 encode it so it can go in a preseed and will the receiving end cope with that
<bigjools> roaksoax: also are you in the process of changing the packaging to depend on the new pgarray?  if not I can do it.
<bigjools> roaksoax: also see last comment on https://bugs.launchpad.net/bugs/1204507 looks like a packaging bug
<ubot5> Launchpad bug 1204507 in maas (Ubuntu Quantal) "MAAS rejects empty files" [Undecided,Confirmed]
#maas 2013-09-11
<smoser> bigjools, not binary. stuff it right into a multi-part part.
<smoser> bigjools,  you can call it really easily.
<smoser> http://paste.ubuntu.com/6090466/
<lifeless> oh hi peoples ;)
<roaksoax> bigjools: pgarray things is done just havent merged
<bigjools> o/ lifeless
<bigjools> roaksoax: great, need a review?
<bigjools> smoser: thanks
<roaksoax> bigjools: it is only add a depency so pretty easy
<bigjools> roaksoax: ok fair enough
<bigjools> roaksoax: that other one looks bad but I've not had time to investigate yet
<roaksoax> bigjools: the bug above, it is not a packaging issue, it is a archive issue, maas-dns maas-dhcp was not "officially supported" in precise
<bigjools> roaksoax: oh is he upgrading from the PPA ...
<bigjools> so many versions of maas about I lose track
<roaksoax> bigjools: the thing is that if you add -proposed and only add main pocket, and you upgrade you wont be able to upgrade you need to add both main and universe
<bigjools> roaksoax: he says this is raring not precise
<roaksoax> bigjools: the same
<roaksoax> maas-dns maas-dhcp are in universe
<roaksoax> just noticed a few days ago
<bigjools> roaksoax: !
<roaksoax> bigjools: i know right, I dunno why it wasn't promoted
<bigjools> roaksoax: isn't there an automated check for that?
<roaksoax> bigjools: i dunno, but I'mgonna request tha
 * bigjools makes coffee
<AskUbuntu> Juju e MAAS get error in apt | http://askubuntu.com/q/344064
<roaksoax> rvba: sorry for the delay: https://code.launchpad.net/~andreserl/maas/packaging_add_depends/+merge/185118
<kurt_> roaksoax: how do you make a second interface available in the maas node.  I see the second interface recognized with second mac addr in the gui, but I don't fully understand how to make it available to a charm.
#maas 2013-09-12
<rvba> roaksoax: Thanks for the packaging fix!  If you still have some spare cycles, we'd be happy to have a backport of the djorm_pgarray package in our backport ppa (ppa:maas-maintainers/backports)â¦ but that's definitely not urgent.  Thanks again!
<freeflying> bigjools, ping
<bigjools> freeflying: I am EOD, can one of the other guys help?
<freeflying> bigjools, of cause, anyone's help would be appreciated
<bigjools> well depends who out of allenap, rvba and jtv1 reads this mass obnoxious ping first :)
 * bigjools EODs
<allenap> freeflying: What's up?
<freeflying> allenap, after node get ip from maas, it fails to get pxelinux.0 from maas, shows tftp timeout
<allenap> freeflying: Are you seeing that time-out on the node, or on the cluster controller (where the tftp server is running)?
<freeflying> allenap, from the node
<freeflying> allenap, tftp sits on server together with maas, its maas builtin tftp
<freeflying> allenap, send you the info(a pic)
<allenap> freeflying: Can you check that the tftp server is running? tftp 10.209.13.207 69 # Enter "get pxelinux.0"
<freeflying> allenap, connection refused
<freeflying> allenap, where shall I restart the tftp server
<allenap> freeflying: I'm trying to find out :) I'm used to working from a branch rather than package...
<freeflying> allenap, ha, thanks
<allenap> frankban_: `restart maas-pserv` I think.
<frankban_> freeflying: ^^^
<freeflying> allenap, it doesn't help :)
<freeflying> frankban_, thanks :)
<allenap> Sorry.
<allenap> freeflying: Can you take a look in /var/log/maas/pserv.log.
<freeflying> allenap, Received  SIGTERM, shutting down;
<allenap> freeflying: Can you tail that file while running `start maas-pserv`?
<freeflying> allenap, so I did stop maas-pserv, then I got the info above, after I do start maas-pserv, nothing from the log
<allenap> freeflying: Can you try the tftp command again?
<freeflying> allenap, surprising, I can download it now
<allenap> freeflying: Let me know if you discover why the tftp server (maas-pserv) wasn't running.
<freeflying> allenap, I will, hope I can find some clue out
<freeflying> allenap, thanks for your help
<allenap> freeflying: No worries, hope it stays fixed :)
<freeflying> allenap, thouth I can downlaod from tftp manually, but node still can't download pxelinux.0 from it
<allenap> freeflying: Have you done http://maas.ubuntu.com/docs/install.html#import-the-boot-images?
<freeflying> allenap, yes, it was a working maas, I changed ip, reconfigure the regional-controller
<allenap> freeflying: Which IP did you change?
<freeflying> allenap, by doing dpkg-reconfigure maas-regional-controller
<freeflying> allenap, I can use tftp cli to download pxelinux.0, and there are logs from pserv.log when doing this
<allenap> freeflying: Is the node unable to load pxelinux.0, or is it failing after that?
<freeflying> allenap, unable to load pxelinux.0
<allenap> freeflying: I'm out of ideas here. Can you wait until roaksoax is online?
<freeflying> allenap, sure, thanks anyway
<allenap> freeflying: Thanks.
<paul_> hi im trying to setup a maas node with pxe but the DHCP isnt responsing. Does anyone know of a solution?
<Tim> Anyone have a idea why a fresh MAAS install would not bring up the web interface?
<paul_> have you setup the superuser?
<Tim> yep
<Tim> and imported the pxe images
<Tim> is it just an apache2 site?
<roaksoax> Tim: did you install maas-dns/maas-dhcp?
<Tim> no, I have another set of machines on the network that are doing PXE DHCP DNS
<Tim> I didn't want them to stomp on eachother
<Tim> roaksoax: But I don't see the site locally either
<roaksoax> Tim: well maas needs to do PXE
<roaksoax> Tim: and you need to tell extenrla DHCP that maas is DHCP
<Tim> roaksoax: Eventually I'll separate the vlans and have maas do those things. Does it need it immediately to run the web frontend
<roaksoax> Tim: so what's the error with the web interface?
<roaksoax> Tim: did you do sudo apt-get install maas?
<Tim> yep
<Tim> roaksoax: brought up the one config screen, and got the ip right
<Tim> but there is no running web api, all I get it the default apache2 site
<roaksoax> Tim: http://your-machine/MAAS
<Tim> http://192.168.100.29/MAAS yields nothing
<Tim> 401
<roaksoax> Tim: what tdoes apache error log say?
<Tim> roaksoax: found it, wasn't interpolating case-sensitivity correctly
<Tim> Thanks!
#maas 2013-09-13
<roaksoax> rvba: don't take you are still around?
<Mtl_> Hey there. I just installed MaaS and saw that It proceeds to automatic server installation with PXE+DHCP+IPMI/WakeOnLan. But I was wondering ... How can it be possible in a real datacenter like OVH ?
<lifeless> Mtl_: you mean ovh.co.uk ?
<Mtl_> yes sir.
<lifeless> if they give you acccess to IPMI and your own layer 2 network for deployment it should work fine
<lifeless> if they don't, then you'd need them to offer you a MaaS endpoint
<lifeless> (or some other bare metal cloud API)
<Mtl_> They offer a kind of "own network" called vRack http://www.ovh.co.uk/dedicated_servers/virtual_rack.xml
<Mtl_> whitch connect dedicted servers with a virtual switch
<Mtl_> By the way, I bet that the Ubuntu Cloud Infrastructure is nothing without MaaS
<lifeless> what do you mean ?
<Mtl_> That the deployment of a Ubuntu Cloud Infrastructure is not possible / useful without MaaS
<lifeless> oh; I wouldn't agree with that statement
<lifeless> though I guess it depends on the exact definition of UCI
<Mtl_> Thanks for all
<lifeless> but you can certainly deploy an OpenStack cloud using Ubuntu packages w/out MaaS
<lifeless> probably still using Juju - e.g. Juju on top of Nova baremetal
<lifeless> in fact https://help.ubuntu.com/community/UbuntuCloudInfrastructure describes three ways to install
<lifeless> only one of which uses MaaS
<Mtl_> Aah right.
<Mtl_> And MaaS is really dedicted for HyperScale
<Mtl_> Like if you have your own datacenter and racking a lot of servers
<Mtl_> to avoid the installation process on workers
<lifeless> Mtl_: yes, it is automation
<lifeless> Mtl_: if you don't have enough hardware to pay off the (time, learning, etc) overhead of installing MaaS, then you don't need it.
<lifeless> Mtl_: but you can still get UCI ;)
<Mtl_> Thanks for help !
#maas 2013-09-14
<AskUbuntu> Does MaaS provide options for High availability or redundancy? | http://askubuntu.com/q/345638
#maas 2013-09-15
<lifeless> bigjools: will you be in HK for ODS?
<bigjools> lifeless: dunno yet, probably not but you never know
<lifeless> bigjools: ah well :) will have to atch up another time then
<bigjools> lifeless: yes indeedy
<AskUbuntu> 12.04 Keystone charm fails to deploy: How do I debug it? | http://askubuntu.com/q/345959
#maas 2014-09-08
<bigjools> jtv: can I make a suggestion about your tmpdir fix
<bigjools> can we put a base name in the tmpdir so we know what it's there for
<jtv> Sure.  There was one before, but I forgot.
<bigjools> yeah
<bigjools> I just realised it was there before, hadn't got that far
<bigjools> oh for side-by-side diffs in LP
<bigjools> jtv: can I archive off your "done" cards on kanban?
<jtv> bigjools: yes please.
<bigjools> done.
<rvba> bigjools: allenap: jtv: gmb: I just filed https://bugs.launchpad.net/maas/+bug/1366726 about the nodes not getting a static IP address.
<ubot5> Ubuntu bug 1366726 in MAAS "CI breakage: Deployed nodes don't get a static IP address" [Critical,Triaged]
<jtv> Looking.
<jtv> rvba: you mentioned that there was a race condition, right?
<rvba> jtv: well, it seems it doesn't happen all the time.  But once the other CI breakage will be fixed, we will know more about the frequency of the problem.
<jtv> So more a placeholder than a full bug report for now?
<rvba> jtv: indeed
 * jtv nods
<rvba> jtv: I thought it was critical enough to file a bug as early as possible.
 * gmb loves finding Blaswell code thatâs untested. Because, Giggles!
<gmb> allenap: Moar halp with twisted pls. Whyfore is this happening http://pastebin.ubuntu.com/8289294/ with this diff: http://paste.ubuntu.com/8289292/
<kickinz1> \o
<kickinz1> Hello, how do remove achitectures from maas (to retrieve only i386 and amd64) ?
<kickinz1> So import can be faster?
<kickinz1> and /var/lib/maas could be smaller (ppa version: 1.6.1+bzr2550+2551+294~ppa0~ubuntu14.04.1)
<gmb> allenap: Never mind. Holy duplicated useFixture batman!
<kickinz1> using maas $Profile boot-source-selections read $Cluster_uuid 1
<kickinz1> had to take cluster_id from webgui, didn't found any other way to get the UUID from cli
<kickinz1> and it tells me 'Not Found'.
<kickinz1> ok got it sorry,
<kickinz1> need to maas $profile boot-source read $cluster_uuid, thne it gives you its "id"
<kickinz1> bye
<jtv> kickinz1: the CLI is horrible â definitely on the list of things we want to improve.
<kickinz1> jtv: thanks for answering, yes cli is not super usable, but I had a conf with arches='*', so near 50Gb of data to download... Maybe it could be insterresting to allow selection of arches within web interface for clusters?
<jtv> kickinz1: definitely something we want â our problem is time!
<kickinz1> jtv, I understand, not a critic ;)
<jtv> No worries. Glad you got this one sorted out.
<kickinz1> jtv, first time I used maas was a long time ago, just when it was renamed from Orchestra to Maas, so I can tell that work has been done meanwhile !
<jtv> Oo!
<jtv> That's a while back.
<kickinz1> Yes and replayed with it lately as I changed from company...
<gmb> allenap: Halp againâ¦ Iâm hitting this: http://paste.ubuntu.com/8290409/ with this diff: http://paste.ubuntu.com/8290398/. Now, I know that thatâs happening because the function is timing out waiting for a connection to the (Mock) regionâ¦ BUt I donât know why *that*âs happening.
<allenap> gmb: Iâll take a look.
<gmb> allenap: Thank you.
<gmb> allenap: In turn, Iâll review your branches.
<allenap> gmb: Thanks!
<allenap> gmb: Donât use the Clock() first.
<gmb> allenap: Okay, what should I do instead? I only use the Clock() as far as creating the ClusterClientService is concerned, and I only need that once Iâm in create_nodeâ¦ Should I just do that there?
<allenap> Clock is useful for writing tests without the reactor, where you can control the advancement of time and observe what happens, but it essentially detaches code from the reactor.
<gmb> Ahh.
<gmb> allenap: So can I just use the reactor in create_node and not have to do anything in the test to make it all sane?
<gmb> i.e.:
<gmb> client_service = ClusterClientService(reactor)
<gmb> ?
<allenap> gmb: Iâm not sure you need the client service anyway; the MockLiveBlah will be arranging for that already.
<gmb> ORLY?
<gmb> Iâve missed something somewhereâ¦
<gmb> allenap: Oh, d'oh!
<gmb> getRegionService()
<gmb> *Client
<gmb> Right, new failures. All good.
<allenap> gmb: http://paste.ubuntu.com/8290586/ (needed to provide a response for the CreateNode stub)
<gmb> allenap: Fab, ta
<gmb> allenap: Remind me, will get_cluster_uuid actually work from within PServ? I know the API credentials stuff doesnât, but that should, shouldnât it?
<allenap> gmb: It depends on the packaging I think, if pserv is invoked with CLUSTER_UUID set :-/ Not a good answer I know.
<gmb> GAAAAH.
<gmb> Thatâs exactly what I was hoping you wouldnât say :)
<allenap> gmb: Actually, it must be okay; lots of other RPC calls use the UUID.
<gmb> allenap: Yeah, I saw the same in plugin.py. Cool.
#maas 2014-09-09
<dimitern> anyone around? I'm having issues with getting maas cli ipaddresses to work
<dimitern> $ maas maas-root ipaddresses reserve network=192.168.50.0/24
<dimitern> No network found matching 192.168.50.0/24
<dimitern> but I can see 192.168.50.0/24 in the networks list with $ maas maas-root networks read
<dimitern> roaksoax, allenap, gmb, rvba`, if you have a moment? ^^
<dimitern> jtv, bigjools, blake_r, jhobbs, or maybe one of you? ^^
<allenap> dimitern: Iâm here, but I have less experience than you with that command :)
 * allenap fires up NUC.
<dimitern> allenap, ah :), sorry to bug you, but it seems the command accepts some format I'm not getting or there may be a bug
<gmb> allenap: Whatâs the nicest way to test the way a function handles an error in an RPC call? Is it to set the side_effect of the RPC call (when using MockLive*Fixture) to defer.fail(Exception(â¦.)) or am I missing something? That way doesnât quite work the way I expected.
<jtv> dimitern: is the cluster interface set to manage DHCP?
<dimitern> jtv, let me check
<jtv> And more importantly, does it have a static range set?
<dimitern> jtv, yes: eth0	192.168.50.0/24	Manage DHCP and DNS	
<jtv> And the static range?
<dimitern> jtv, hmm, that might be it - how to check?
<jtv> Because that's where the static IP address comes from.
<jtv> Look at the cluster interface in the UI.
<jtv> (Well, or the API, but UI is easier.)
<dimitern> jtv, there's nothing in the Non-MAAS DHCP column
<jtv> That's OK.
<jtv> That's just a check for rogue DHCP servers on the network.
<jtv> But click on to the page for that specific interface, and you should see a dynamic address range and a static address range.
<jtv> If it only has the dynamic range, then you can't reserve static IP addresses because there's no address range to take them from.
<dimitern> jtv, it indeed did have only dynamic ranges, I added static low-high, but the cluster edit page still does not show anything in Non-MAAS DHCP
<jtv> Are you running a DHCP server on that subnet that's not managed by MAAS?
<dimitern> jtv, nope, maas is running inside kvm on a dedicated bridge, so it's isolated from the rest of the network
<dimitern> jtv, and after adding the static range it did work! thanks!
<jtv> The Non-MAAS DHCP field is there only to show you if there are any DHCP servers running on the subnet that MAAS isn't in charge of.  Empty is its normal, "everything OK" state.
<dimitern> jtv, I see
<dimitern> jtv, but I have to note that as a dumb user the "No network found matching 192.168.50.0/24" error message when there's no static range set isn't very helpful :)
<jtv> Indeed.
<jtv> File a bug?
<dimitern> jtv, will do, thanks
<allenap> gmb: Sorry, I missed your question until now. /me thinks.
<gmb> No worries
<allenap> gmb: Yeah, set side_effect.
<allenap> gmb: Whatâs not working quite right?
<dimitern> bug filed: https://bugs.launchpad.net/maas/+bug/1367197
<ubot5> Ubuntu bug 1367197 in MAAS "maas-cli ipaddresses reserve network=CIDR error message unhelpful" [Undecided,New]
<bigjools> jtv. dimitern: I was *just* looking at the code that does that 10 minutes ago and thinking... hmm this will give the wrong error!  And guess what ...
<gmb> allenap: http://paste.ubuntu.com/8298444/ produces  http://pastebin.ubuntu.com/8298451/
<jtv> bigjools: told you it'd make more sense to match on the full network before checking against just the static range.  :)
<bigjools> jtv: meh
 * bigjools goes afk
<dimitern> bigjools, :) indeed
<dimitern> dogfooding IS king
<allenap> gmb: Iâs investigatin'
<gmb> Ta
<allenap> gmb: I canât apply that to trunk. Do you mind merging trunk and diffing again?
<gmb> Gnargh.
<gmb> allenap: Sure
<gmb> (As in âSure, no problem,â not âyes, I mind, you cheeky swine."
<gmb> allenap: http://paste.ubuntu.com/8298498/
<gmb> allenap: or lp:~gmb/maas/create-node-to-use-RPC
<allenap> gmb: I think mock is getting confused over the use of both return_value and side_effect. http://paste.ubuntu.com/8298529/ is my fix.
<gmb> allenap: Ah, sweet. Thanks.
<gmb> allenap: Also, didnât know you could have a list of side_effects. Nice!
<allenap> gmb: Yeah, I didnât know that until relatively recently.
<dimitern> allenap, gmb, re that bug I filed, is it hard to change the error message in that case?
<dimitern> I mean it's something that will probably hit us sooner rather than later, however trivial it might seem
<dimitern> so IMHO it should be triaged as High perhaps
<bigjools> dimitern: it's not trivial to fix
<bigjools> priority reflects the reality of when it will get fixed, not how important it is
<dimitern> bigjools, I see, ok then
<bigjools> having said that, I'll take a look tomorrow
<dimitern> bigjools, thank you ever so much :)
<bigjools> :)
<jtv> caribou: yes, "bzr branch," commit & push changes, then "propose for merging" into lp:maas.
<caribou> jtv: work is done on the upstream branch or the Ubuntu one (i.e. lp:ubuntu/maas) ?
<caribou> jtv: I have another question but I'll ask in the Freenode channel
<caribou> oh, I am now
<caribou> man I need to figure out a way to discriminate b/w two channels with the same name
<caribou> ok, I'm working on another bug : when installing maas-cluster-controller, the postinst script runs "chown -R /var/log/maas"
<caribou> in doing this, it changes the ownership of /var/log/maas/rsyslog & the syslog daemon can no longer write to it
<caribou> would the following change to the postinst script be adequate for you : http://paste.ubuntu.com/8299594/
<jtv> caribou: the work is done on the upstream branch.
<caribou> jtv: perfect!
<jtv> I guess /var/log/maas needs syslog as its group then..?
<caribou> jtv: before installing maas-cluster..., the ownership is correctly set to syslog:syslog
<caribou> jtv: the maas-region-controller.postinst script does it correctly
<caribou> jtv: it is just the blanket change by "chown -R" in the maas-cluster pkg that messes things up
<jtv> Oh, what you're proposing is already in the region postinst?
<caribou> jtv: no, the region sets up /var/log/maas as owned by syslog:syslog, but then installing the maas-cluster behind it resets it to maas:maas
<jtv> Do we know that maas will still be able to do all the logging it needs, e.g. after log rotation?
<caribou> jtv: so if I do the normal "apt-get install maas", /var/log/maas/rsyslog is owned by maas:maas & the syslog daemon cannot write to it
<caribou> jtv: if I only install the maas-region-controller package (for testing purpose), then /var/log/maas/rsyslog is owned by syslog:syslog
<jtv> Yes, so the question is: will the cluster controller be able to log when it's like that?
<caribou> jtv: well, doing the 'find .' in http://paste.ubuntu.com/8299594/ will change everything bug rsyslog to maas:maas so I suppose that it will work
<caribou> jtv: one thing is sure : /var/log/maas/rsyslog when owned by maas:maas doesn't work
<jtv> Right.
<jtv> I guess it'll work in either installation order?
<jtv> (Sorry, evening here, tired!)
<caribou> jtv: no worry, it's not obvious out of the context
<caribou> jtv: I'll propose a branch & test my stuff before hand. then you people can judge
<jtv> If comments are possible, add them!
<jtv> Thanks.  :)
<caribou> jtv: thank you
<jtv> Don't thank me.  You're the one writing the patch.  :)
<caribou> hmm, the change I was talking about previously is in a debian packaging specific file; should I do the MP from the lp:ubuntu/maas branch ?
<lamont> if tcpdump shows the ipmi packets going from the controller to the ilo on the HP DL 360 blade, and it doesn't power on, what are the most likely suspects?
<gmb> allenap: Calling allenap-as-a-serviceâ¦ Why does http://paste.ubuntu.com/8300331/ give me http://paste.ubuntu.com/8300352/?
<gmb> allenap: Nevermind. Fixed it.
<gmb> allenap: Oh, wait, no I haven't.
<rvba> gmb: I was surprised to see https://bugs.launchpad.net/maas/+bug/1357071.  I thought we were using a wrapped around system calls but apparently, this is coming straight from the Python libraryâ¦ any idea on how we could fix this?  I'm asking because I'm not sure Blake's big replacement is going to be done in time for the release.
<ubot5> Ubuntu bug 1357071 in MAAS "When a power template fails, the content of the event from the node event log is not readable (it contains the whole template)" [High,Triaged]
<gmb> rvba: I have no clever ideas off the top of my headâ¦ bear with me a sec.
<gmb> allenap: Iâm completely stuck with the problem I pung you with last. Whenever youâve got a chance to eyeball it, itâd be appreciated.
<gmb> rvba: I need some context. Where in the code is that error actually coming from?
<rvba> gmb: that's the thing, I tried to change ExternalProcessError.str (or whatever it's called) and couldn't get a different representation of the error.
<gmb> !
<rvba> gmb: then I hacked /usr/lib/python2.7/subprocess.py:CalledProcessError and *this* changed the error
<gmb> Ooo-kay
<rvba> That's why I was surprised, I thought we were using a wrapper each time we need to shell something out.
<gmb> rvba: Well, isnât the offending code in src/provisioningserver/power/poweraction.py?
<gmb> That doesnât use our wrapper (why? IDK)
<gmb> It uses subprocess directly.
<gmb> rvba: See PowerAction.run_shell()
<gmb> rvba: So maybe a first step is to change that to use our call_and_check wrapper.
<rvba> gmb: yeah, probably.
<rvba> gmb: I was just wondering why we didn't use that already.
<gmb> rvba: No clue, Iâm afriad. We (I?) mustâve missed that when switching things over to use call_and_check.
<gmb> allenap, rvba, blake_r, jhobbs: https://code.launchpad.net/~gmb/maas/create-node-to-use-RPC/+merge/233899 needs a review, please.
<blake_r> gmb: done
<gmb> blake_r: Thx
<gmb> allenap: Youâve got a bunch of cards in the review lane for celery removal, but I donât see any branchesâ¦ are those ones all done, or am I jumping the gun?
<gmb> Yay, test isolation problems!
<gmb> But theyâre for tomorrow.
<allenap> gmb: Theyâre reviewed, just not landed yet.
#maas 2014-09-10
<bigjools> jtv: was there a good reason to optimise the lease sending to the region so it didn't send them if there were no changes?
<bigjools> I ask because of this bug with static IPs; if the leases are sent before the node is in maas then the cluster_interface link is never made
<bigjools> so I have two choices to fix this: 1. send all leases every time, 2. add a separate job to parse the in-DB ones
<bigjools> well "parse", read and apply the link I mean
<jtv> bigjools: the reason was just generic worry about size, not any problem that we encountered in practice.
<jtv> Is this what's been causing the bug where nodes didn't get static addresses in CI?
<jtv> It's not a matter of checking at MACAddress creation time whether a lease existed?
<bigjools> jtv: that would be a third solution yes
<bigjools> jtv: ok, I did it that way: https://code.launchpad.net/~julian-edwards/maas/always-send-leases/+merge/234052
<jtv> bigjools: funny how that problem pattern keeps cropping up in software.
<bigjools> jtv: which one?
<jtv> Having to detect that a combination of two events have occurred both when one occurs and when the other occurs.
<bigjools> ah yes
<bigjools> I thought about using signals, and then I slapped myself in the face and woke up
<gmb> allenap: Branch: lp:~gmb/maas/port-add-virsh-to-rpc ; bin/test.maas maasserver.models.tests.test_nodegroup produces http://paste.ubuntu.com/8307588/
<gmb> (this is the "Twisted is twisting my melon" problem, not the isolation problem.")
<allenap> gmb: /me looks
<gmb> allenap: The "expected to be calledâ¦" thing I understand; it's the __call__ takes 2 arguments bit that I'm fuzzy on.
<allenap> gmb: In NodeGroup.add_virsh you need to use keywords for all arguments (other than the command) when using the client.
<gmb> allenap: AAAAAAAAAAAAAH
<gmb> allenap: Can we improve that error, or is that upstream (looks like upstreamâ¦)
<jtv> bigjools: I need to get a node's StaticIPAddress objects, but Node.static_ip_addresses returns address strings, not the objects.  Would it make sense to split out the part that returns StaticIPAddress objects?
<bigjools> jtv: no, one moment OTP
<caribou> jtv: remember my rsyslog query yesterday ? The MP for it is in Bug #1346703
<ubot5> bug 1346703 in maas (Ubuntu) "/var/log/maas/rsyslog has incorrect permission" [Medium,In progress] https://launchpad.net/bugs/1346703
<allenap> gmb: We can improve that error; Iâll sort it out.
<gmb> allenap: Thanks. I was also missing a .wait(), but the error for that is *amazingly* helpful. I'm going to assume you wrote the code that generates it, so _thank you_.
<jtv> caribou: that explains why I didn't see it on the reviews list â we normally work against the upstream branches!
<jtv> In this case, that'd be lp:~maas-maintainers/maas/packaging
<caribou> jtv: I know, but the fix is on the debian packaging files which are not on the dev branch
<jtv> We have separate upstream branches for those  ^
<caribou> jtv: ah, so you have a specific branch for the packaging; want me to do the MP against this branch ?
<jtv> Yes please!
<jtv> You can probably just hit Resubmit.
<caribou> jtv: sure, will do right now
<bigjools> jtv: ok sorry I misread, yes, split it out
 * bigjools back later
<caribou> jtv: I *manually* tested it on Utopic; seems to work fine
<caribou> jtv: i.e. I rebuilt the packages & installed the debs
<jtv> Thanks bigjools
<jtv> caribou: if you check out lp:maas and cd into it, you can just run "make package" â will create packages in ../build-area
<jtv> (Bit weird as a location, but otherwise very convenient)
<caribou> jtv: good to know. I build so many pkg that debuild -S && sbuild are my friends
<caribou> jtv: ok, I just resubmitted to lp:~maas-maintainers/maas/packaging
<caribou> jtv: regarding Bug #1367266, want me to do a MP for this one as well ?
<ubot5> bug 1367266 in maas (Ubuntu) "missing dependancy for python-pexpect for maas-region-controller" [Undecided,New] https://launchpad.net/bugs/1367266
<caribou> I saw that there was already the same for maas-cluster-controller
<jtv> caribou: first let's see if allenap knows more.  We may also want to add it to one of the lists in required-packages (in the main source branch) to facilitate development.
<caribou> jtv: ok, fine. as long as it is referenced somewhere. I just stumbled over it while testing the other bug
<jtv> allenap: do you know more about maas-region-controller needing python-pexpect installed?  Seems to be a missing or misplaced dependency.
<jtv> caribou: weird, now I don't see your MP at all...
<caribou> jtv: lemme check; I'm far from being a pro @bzr
<caribou> jtv: http://goo.gl/qvxu1g
<jtv> caribou: it's got a conflict, too.  :(
<jtv> Grrr.  That resubmit did not work out the way I hoped.  :(
<jtv> I'm sorry about that.
<caribou> jtv: nevermind, it's only a few minutes to destroy it & redo
<caribou> jtv: let me do it the proper way
<jtv> Thanks.
<allenap> jtv: I suspect thatâs for virsh support via SSH. blake_r?
<jtv> blake_r: do you know about the maas-region-controller package seemingly missing a dependency on python-pexpect?
<allenap> gmb: Up for a review? https://code.launchpad.net/~allenap/maas/rpc-better-client-error/+merge/234077
<gmb> allenap: Sure
<gmb> allenap: Lovely. Thankee :)
<caribou> jtv: it's there I think : https://code.launchpad.net/~louis-bouchard/maas/lp1346703_rsyslog_ownership/+merge/234080
<jtv> caribou: I will have to leave very soon...  still not seeing it on the list for some reason!
 * jtv checks again
<jtv> Oh yes, there it is.
<caribou> jtv: no worry, it can wait until tomorrow
<caribou> jtv: or later
<jtv> Why does everybody have names of such similar lengths?  :)
<jtv> Thanks.
<gmb> allenap: In turn, here's my AddVirsh branch. https://code.launchpad.net/~gmb/maas/port-add-virsh-to-rpc/+merge/234082
<gmb> (If you've time)
<jtv> caribou: I set a commit message (otherwise tarmac won't land the branch, but not complain either).  One thing still looks off: why did the top of the changelog get sliced off?
<caribou> jtv: fine; Re: changelog I don't know
<jtv> bigjools: drat, I need all of a node's IP/MAC mappings, but StaticIPAddress doesn't directly refer to the MAC.  We don't have anything ready-made for that, do we?
<jtv> caribou: have a look at the diff on the MP... a big red section there.
<caribou> jtv: oh, crap my fault; lemme fix it
<jtv> :)
<caribou> jtv: should I just uncommit & fix it or do a new commit ? (told you I was bad at bzr)
<jtv> caribou: uncommit is fine, but when you push it back up, the revision will still be on the server.  To get around that, push with the --overwrite option.
<caribou> jtv: k
 * jtv runs
<jtv> nn folks!
<rvba> nn jtv
<caribou> ok, MP is fixed, jtv can have a look at it tomorrow
<gmb> allenap (and maybe rvba; this is part-Django): I have a problem with lp:~gmb/maas/create-node-to-use-RPC. jtv was right about the source of the isolation problem, but now I can't get one of my tests to workâ¦ bin/test.maas src/maasserver/rpc/tests/test_nodes.py:TestCreateNode.test_creates_node always produces the following: http://paste.ubuntu.com/8308294/. I've used set_trace() to check that MACAddresses are actually getting created for the node â th
<gmb> rvba, allenap: Diff here, for reference: http://paste.ubuntu.com/8308308/
<allenap> gmb: Iâll take a look.
<gmb> allenap: Thanks.
<gmb> allenap: Also, thanks for the review; I thought I'd pushed a version of that branch without the "spoons" logger, which was for debugging purposes :)
<allenap> gmb: I like it though. Letâs see if we can introduce it via acronym/bacronym.
<gmb> :)
<gmb> Synchronous-Procedural-Object-Oriented-Networking
<allenap> gmb: That was a tricky one. Iâm surprised we havenât seen it before. http://paste.ubuntu.com/8308719/ fixes it.
<allenap> gmb: Iâll write a test for that.
<allenap> gmb: Iâll put it up for review.
<allenap> gmb: https://code.launchpad.net/~allenap/maas/transactional-close-connections-on-outermost-exit-only/+merge/234092
 * allenap goes for lunch
<gmb> allenap: Many thanks!
<blake_r> jtv: that dependency should be on python-provisioningserver not on maas-region-controller
<caribou> allenap: I'm find with your suggestion, I'll fix the branch & push it back
<allenap> caribou: Cool, thanks.
<caribou> allenap: out of curiosity, what's wrong with -exec on the find cmd ? it forks one proc for each one it finds ?
<roaksoax> jamespage: what dependency is this?
<caribou> allenap: Done, just pushed the requested change
<jamespage> roaksoax, ?
<roaksoax> jamespage: sorry :) wrong nick!
<jamespage> roaksoax, np
<allenap> caribou: Ta!
<caribou> allenap: thanks
<rvba> allenap: is the cluster supposed to be connected in a dev environment?  I mean, does a dev environment mimics what's happening in a package w.r.t. cluster<->region connection?
<allenap> rvba: It should be, yes.
<rvba> allenap: hum, it doesn't seem to work (my code works fine from a package, I see the result of my method change when I start and stop pserv).  I'll investigate.
<allenap> rvba: If itâs not working, bigjools filed bug 1361037 which might be relevant.
<ubot5> bug 1361037 in MAAS "If pserv comes up before the region controller, it will never connect" [Critical,Triaged] https://launchpad.net/bugs/1361037
<rvba> Ah, that might be itâ¦
<roaksoax> caribou: have you ever seen find being used in postinst scripts?
<roaksoax> caribou: i'm not comfortable on applying that fix
<roaksoax> to packaging
<roaksoax> caribou: nevermind, found packaging that uses it
<gmb> Branch up for review, for them as has time: https://code.launchpad.net/~gmb/maas/port-add-seamicro-to-RPC/+merge/234148
<gmb> allenap: Any idea why http://paste.ubuntu.com/8310773/ would produce http://paste.ubuntu.com/8310796/?
<gmb> It succeedsâ¦ whilst talkign about a failure.
<gmb> Which is suboptimal
<allenap> gmb: /me looks
<gmb> allenap: I'm guessing that I'm just missing something twistedy
<allenap> gmb: Can you run with -v to see which test thatâs being emitted from?
<gmb> ure
<gmb> sure
<gmb> allenap: Oh, durr! found the problem. I had find_ip_via_arp() returning None in another test.
<gmb> allenap: Thanks for the hint :)
<allenap> gmb: Cool :)
<roadmr> hello maas folks :) I have a custom image I'd like to deploy using maas (it's a tar.gz that should be "curtin-ready"). How do I make maas aware of it so I can have a node installed with it?
<caribou> roaksoax: I had concerns about using find as well
<allenap> gmb: Easy karma? https://code.launchpad.net/~allenap/maas/pserv-dhcp-removals/+merge/234153
<gmb> allenap: Karma acheived.
 * gmb -> out for the evening. Night folks; see you on the morrow.
<allenap> gmb: Thanks, have a good evening.
<allenap> blake_r: You landed something today (I probably reviewed it evenâ¦) re. boot images, iirc. How close are we to not needing the report_boot_images Celery task any more?
<roaksoax> caribou: yeah, so provided that there's similar stuff in other packages, I'm happy to keep it
<roaksoax> blake_r: ^^
<roaksoax> blake_r: to allenap's query?
<blake_r> allenap: almost there for not needing the celery task, all the api calls, and the boot image table completely
<blake_r> allenap: i will remove them once its ready
<lamont> ERROR 2014-09-10 19:28:05,325 maasserver ################################ Exception: 'Expired timestamp: given 1410376478 and now 1410377285 has a greater difference than threshold 300' ################################
<lamont> what usually causes that?
<blake_r> lamont: the time on the node is 5minutes different than the server
<lamont> freshly provisioning node..  I would expect it to run ntpdate, no?
<roaksoax> lamont: cloud-init might have a race.. cloud-init is the one who takes care of ensure the clocks are the same
<blake_r> roaksoax: https://code.launchpad.net/~blake-rouse/maas/fix-cluster-image-syncing/+merge/234192
<blake_r> roaksoax: fixed ^
<lamont> ta
<roaksoax> blake_r: awesome! does that fix the eveyr 15 min import?
<blake_r> roaksoax: yep
<roaksoax> blake_r: ok great! so multipart is also done?
<blake_r> roaksoax: yep, both up for review
<roaksoax> blake_r: awesome! then the only thing left is psycopg?
<roaksoax> blake_r: has upstream said anything else?
<blake_r> roaksoax: yes
<blake_r> roaksoax: needs to be fixed, for if the client is 9.3 but the server is 9.2
<blake_r> roaksoax: needs to be fixed, for if the client is 9.3 but the server is <9.2
<roaksoax> blake_r: ok, so, that would be the last blocker to support large images then
<blake_r> roaksoax: yes
<roaksoax> blake_r: anychance you can take care of that today ?
<blake_r> roaksoax: hopefully
<roaksoax> blake_r: awesome! thanks for the hard work
<roaksoax> this is awesome
<blake_r> roaksoax: np
#maas 2014-09-11
<mbruzek> hello bigjools
<mbruzek> Do you have a minute to help with a maas question?
<mbruzek> /etc/maas/dhcp.conf is not being populated and i can not start the maas-dhcp-server
<bigjools> rvba: I looked at the power error log thing
<bigjools> the only solution for this, apart from a python rewrite, is to write the generated template to a file and execute it
<rvba> bigjools: can't we use our tiny wrapper that we use everywhere to execute shell scripts and specialize the way errors are built?
<bigjools> what tiny wrapper?
<rvba> Or rather, can't we tweak how we build the PowerActionFail error (http://paste.ubuntu.com/8316602/)?
<rvba> That's the wrapper I had in mind, it's only a wrapper (so to speak) around the error.
<bigjools> oh and CI is failing :(
<bigjools> juju bootstrap
<rvba> Damn.
<rvba> Consistently?
 * rvba checks
<bigjools> yes
<bigjools> rvba: no we cannot tweak it, the error text is returned from check_output
<rvba> bigjools: well, the error we get from check_output has all the information we need stored on it.  Only it's __str__ method produces garbage in our case.
<rvba> bigjools: subprocess.py http://paste.ubuntu.com/8316633/
<bigjools> rvba: it's not garbage, check output does something like "command: error text"
<bigjools> and command in our case is the template
<bigjools> it's abusing the check_output stuff really
<rvba> Yeah, I know; but for power command the template is too much information to put in an event :).
<rvba> commands*
<bigjools> what I might do is use subprocess.communicate and grab stderr separately
<bigjools> although the power templates (I'm looking at AMT) produce  way more output than required
<rvba> Exactly
<rvba> bigjools: it looks to me that the problem is line 6 here http://paste.ubuntu.com/8316645/
<rvba> Because we call the exception's __str__ method.
<rvba> And for errors generated by power templates failing, it's guaranteed that it contains the whole template.
<bigjools> rvba: we can cheat and grab e.output I suppose
<bigjools> but the template needs fixing
<rvba> Indeed.
<rvba> bigjools: but yeah, we could use e.output and e.returncode and not use e.cmd (as e.__str__ does).
<bigjools> rvba: oh god look at what it's doing
<bigjools> line 6 does the __str__
<bigjools> then line 10 does e.output *again*
<rvba> heh, true :)
<bigjools> I'll propose a change
<bigjools> easier than I thought
<bigjools> in the meantime, please review my branch :)
<rvba> I'd love to.
<rvba> Already approved by Dr. jtv it seems.
<jtv> Sorry.  :-P
<jtv> And by the way I never finished that PhD...
<bigjools> aha
<rvba> jtv: I knowâ¦ it was more of honorific title.  For some reason I was thinking about 'Doc' in "Back to the Future". ;)
<jtv> I'll just take that as a compliment.  :)
<bigjools> rvba: I'm the one with unruly grey hair, not jtv
<jtv> I don't know how to break this to you but... it's not unthinkable that I'm slightly weirder.
<caribou> jtv: I'm preparing the SRU for bug #1346703
<ubot5`> bug 1346703 in maas (Ubuntu) "/var/log/maas/rsyslog has incorrect permission" [Medium,In progress] https://launchpad.net/bugs/1346703
<jtv> Hi caribou.  Excellent.
<caribou> should I do a debdiff against trusty-proposed or another MP ?
<caribou> I would say it depens on who sponsor my upload
<jtv> caribou: I don't recall having done any backports on the packaging branch myself, so not sure.
<caribou> jtv: I'll attach a debdiff & add sponsors & SRU team; this is what I usually do
<caribou> jtv: if needed I'll change it later no big deal
<jtv> You might ask bigjools, but I think it's past the end of his day now.
<gmb> allenap, rvba, jtv: https://code.launchpad.net/~gmb/maas/enlist-mscm-to-RPC/+merge/234279 and https://code.launchpad.net/~gmb/maas/enlist-uscm-to-RPC/+merge/234285 need reviewing when youâve got a sec.
 * jtv has a sec
<rvba> gmb: I'll review your other branch.
<caribou> jtv: will do, I should be able to catch him later
<gmb> jtv, rvba: ta
<jtv> Race conditions ftw
<jtv> At last I find out what happens when you try to claim a review that someone else has just claimed.
<rvba> allenap: I wonder if what's seeing in the lab is not two bugs combined.
<rvba> what we are*
<rvba> allenap: I see two errors:
<rvba> maas-integration.TestMAASIntegration.test_check_nodes_declared ... ERROR
<rvba> Or
<rvba> maas-integration.TestMAASIntegration.test_juju_bootstrap ... ERROR
<allenap> rvba: Where are you seeing that? On the run I kicked off test_check_nodes_declared is ok...
<rvba> allenap: we landed a bunch of branches since the first failure.
<rvba> And when I go through them, I see two different type of failures.
<rvba> allenap: I wonder if you haven't reverted one problem, only to get the failure from the other problem.
<rvba> allenap: makes sense?
<allenap> rvba: Ah ha, yes :)
<gmb> allenap, rvba: Another branch for you: https://code.launchpad.net/~gmb/maas/useful-noconnectionerrors/+merge/234319
<rvba> gmb: I'll take it.
<gmb> Ta
<rvba> gmb: question for you on the MP.
<blake_r> allenap: https://bugs.launchpad.net/maas/+bug/1368269
<ubot5> Ubuntu bug 1368269 in MAAS "internal server error when deleting a node" [Critical,Confirmed]
<roaksoax> rvba: ^^
<rvba> roaksoax: blake_r: yeah, ugly bug. The exception is a bit confusing though.  allenap will probably have an idea.
<blake_r> rvba: yeah rpc error
<gmb> rvba: Good point! Updated and pushed.
<gmb> rvba: hang on; test in the wrong placeâ¦ fixing
<rvba> gmb: is it worth changing src/maasserver/rpc/regionservice.py:getClientFor as well?
<gmb> rvba: Definitely. I hadnât spotted that one.
<roaksoax> gmb: so all the probe-and-enlist are finished already right?
<gmb> roaksoax: Yes, theyâre finished now.
<gmb> rvba: Iâve updated that branch again.
<roaksoax> gmb: awesome!
<gmb> rvba: Oh, you already approved. Ta :)
<gmb> roaksoax: Indeed :).
<blake_r> rvba: https://bugs.launchpad.net/maas/+bug/1368269
<ubot5> Ubuntu bug 1368269 in MAAS "internal server error when deleting a node" [Critical,Confirmed]
<blake_r> rvba: that breaks juju bootstrap
<blake_r> rvba: that is what your seing in CI
<blake_r> rvba: i have a fix, for the enlistment issue
<rvba> blake_r: okay, well sleuthed.  allenap will have a look at this in a bit.
<roaksoax> rvba: heh...so this wasn't related to blake_r 's branches after all
<blake_r> roaksoax: enlsitment was!
<rvba> roaksoax: well, yes and no.
<roaksoax> hehe ok :)
<roaksoax> ok, let's get this fixed asap since we are releasing today
<blake_r> rvba: https://code.launchpad.net/~blake-rouse/maas/fix-enlistment/+merge/234326
<blake_r> rvba: one liner!
<rvba> blake_r: which means you're missing a test :)
<blake_r> rvba: naw, its twisted!
<blake_r> rvba: haha!
<rvba> blake_r: do we really want to ignore all failures like that?
<blake_r> rvba: we do for windows boot method
<rvba> I mean don't you want to only silence No Content error errors
<blake_r> rvba: i want to silence all errors, because if windows boot method can't be used, that is fine
<blake_r> rvba: this is only used for the deprecated windows install, that is not supported anymore
<blake_r> rvba: it is unrelated to curtin
<blake_r> rvba: we might remove it
<rvba> blake_r: okay, makes sense;  probably worth a comment in the code though :)
<blake_r> rvba: okay added comment
<rvba> Ta
<plars> matsubara: got a sec? trying to sort out a maas issue
<matsubara> plars, yep
<matsubara> what's up?
<plars> matsubara: I have an install here on trusty that I haven't messed with in a while, but it was previously working.  When I powered it back up to try something I tried to go to the /MAAS page on my server and got a 500 error
<plars> matsubara: so I updated to the latest in trusty and rebooted, still no luck
<plars> matsubara: I'm now on the one in ppa:maas-maintainers/stable, but it's doing the same to me
<matsubara> plars, are you using any version from the PPAs?
<plars> matsubara: sec and I'll post the oops
<matsubara> thanks
<plars> matsubara: previously I wasn't, but I tried the ppa one as a last effort
<plars> matsubara: http://paste.ubuntu.com/8322024/
<matsubara> the only thing I see in that pastebin is a $
<matsubara> plars, ^
<plars> matsubara: hmm
<plars> sec
<plars> matsubara: try http://paste.ubuntu.com/8322034/
<matsubara> Do you have the full traceback for that oops in /var/log/maas/oops? Are there any other tracebacks in /var/log/maas/maas.log or /var/log/maas/celery.log (assuming you are using 1.6 from the stable PPA)
<matsubara> plars, ^
<matsubara> plars, also worth checking if all services for maas are running: maas-pserv, maas-txlongpoll, maas-cluster-celery and maas-region-celery
<matsubara> plars, rabbitmq-server too
<plars> matsubara: sec, phone
<matsubara> but there's probably a more informative traceback in somewhere in /var/log/maas or /var/log/apache2/
<plars> matsubara: don't see anything that looks like a real traceback, but still looking, one moment
<matsubara> plars, ok. Another thing, did you upgrade from 1.5? If you did you'll likely have to re-import the boot images (unrelated to the 500 error you're seeing, just a heads up)
<plars> matsubara: good to know, but I can't even get that far at the moment :)
<plars> matsubara: found some possible stuff http://paste.ubuntu.com/8322192/
<plars> matsubara: that's from error.log
<matsubara> plars, it's taking forever to load that pastebin, is it a huge paste?
<plars> matsubara: yes
<plars> matsubara: I can chop it up if you like
<plars> matsubara: there's a lot of 'error: [Errno 113] No route to host' in it
<plars> I'm not sure which host, perhaps the node that's turned off at the moment?
<plars> matsubara: try http://paste.ubuntu.com/8322257/ for a short one
<matsubara> plars, is rabbitmq-server running? I'd say the region controller is trying to connect to it but failing
<matsubara> plars, when you upgrade did maas restart the services after the update?
<plars> matsubara: yes, it's running
<plars> matsubara: the first update to trusty latest, for certain it did, I even rebooted the whole box to be sure
<plars> matsubara: I'm not sure what all services need to be restarted, I trusted the package update to take care of that but I can reboot again after the upgrade to the ppa version
<matsubara>  maas-pserv, maas-txlongpoll, maas-cluster-celery and maas-region-celery should be all up
<matsubara> as well as rabbitmq-server
<beisner> plars, matsubara - i think the one time i had 500 issue in maas, it ended up being an mq auth issue.   i think there were also some bugs where the rabbitmq pwd was reset during an upgrade.
 * beisner thinks back
<matsubara> beisner, good point
<matsubara> plars, another thing worth checking is the config files in /etc/maas/ and see if DEFAULT_MAAS_URL and MAAS_URL look sane
<matsubara> as in, are they pointing to the URL/ip you'd expect MAAS to be running?
<plars> matsubara: hmm, no one of them points at localhost/MAAS
<matsubara> plars, where are they pointing to? I'd expect to be one of the IPs for that machine.
<plars> matsubara: it is, but....
<plars> matsubara: when grepping through there I think I may have found the problem
<plars> matsubara: somehow the celery broker url seems to be pointing to the wrong IP
<matsubara> plars, there's code in the package to auto detect the default route for the given system and use that IP address as the DEFAULT_MAAS_URL which in turn the MAAS_URL would infer its value from. The package would respect the values if they're set into the debconf db but if the configs were changed manually directly in the file they might be overwritten.
<matsubara> plars, but if you can reproduce the issue or describe what you did, I think it's worth filing a bug. It's helpful to have this kind of upgrade feedback.
<plars> matsubara: seems to be working now, somehow I think I just had a bad ip. Thanks!
<matsubara> plars, cool! You're welcome.
#maas 2014-09-12
<rvba> allenap: I'm trying to test some things but bug https://bugs.launchpad.net/maas/+bug/1365742 is getting in the way.
<ubot5> Launchpad bug 1365742 in MAAS "Logged OOPS ... NoSuchEventType: Event type with name=NODE_POWER_ON_FAILED could not be found." [High,Triaged]
<rvba> I'm seeing http://paste.ubuntu.com/8325785/ over and over.
<rvba> What does the "No exception type: No exception value" error mean?
<allenap> rvba: Okay, Iâll look at that now.
<rvba> allenap: Ta, I'm happy to help (I really need this solved).  Let's work together on this.
<rvba> allenap: any idea what might be wrong?
<gmb> allenap: When youâre done helping rvba, do you have time to chat about serialising power commands? (This is the thing that Kiko reckons needs Face Time. Iâm not so sureâ¦)
<allenap> rvba: Nope, not yet. Iâm going to try and reproduce it on my NUCs. Or can I reproduce it in a dev environment?
<allenap> gmb: Yes indeedee.
<rvba> allenap: I think you need real systems.
<allenap> Hereâs one I prepared earlier...
<rvba> allenap: I put debugging statements everywhere in send_event_node (src/provisioningserver/events.py) and I can see that everything looks normal: no need to register the event type (because it already exists) and I still see the exception in pserv's log!
<gmb> allenap: Cool. Ping when free, then.
<rvba> allenap: https://bugs.launchpad.net/bugs/1368685 â¦ weird, never seen thisâ¦
<ubot5> Launchpad bug 1368685 in MAAS "After commissioning NUC reboots instead of shutting down" [High,Triaged]
 * gmb -> lunch
<allenap> rvba: I canât reproduce https://bugs.launchpad.net/maas/+bug/1365742 now.
<ubot5> Launchpad bug 1365742 in MAAS "Logged OOPS ... NoSuchEventType: Event type with name=NODE_POWER_ON_FAILED could not be found." [High,Triaged]
<allenap> rvba: What do you do?
<rvba> allenap: I just uninstall amtterm and commission nodes.
<allenap> rvba: I think I see what it might be. Try applying http://paste.ubuntu.com/8326460/ to a branch and running bin/test.pserv.
<allenap> rvba: The power commands mix synchronous and asynchronous code and get it slightly wrong.
 * rvba reads the docstring of the 'synchronous' decorator.
<rvba> allenap: the decorators are just belt and braces right?  The real changes are 'yield' and 'wait' correct?
<allenap> rvba: They are, yes, though the asynchronous decorator does automatically use crochet when calling an async function from outside of the reactor.
<rvba> allenap: all of this code runs in pservâ¦ why is crochet involved at all?
<allenap> rvba: It shouldnât be in pserv; thatâs really for the benefit of the region. Thatâs what alerted me to this problem, because I saw mention of EventualResult in pserv.log.
<rvba> allenap: why shouldn't it be in pserv?  The cluster is in charge of all the power-related operations.  Then it reports back to the region via RPC.
<allenap> rvba: Fwiw, the crochet functions run_in_reactor and wait_for_reactor are okay to use in pserv, though theyâre not needed much. We just donât want to use crochet to start up the reactor there.
<allenap> rvba: I mean crochet shouldnât be used (much) in pserv.
<rvba> My understanding was that crochet was only there as a bridge between Django and twisted.
<allenap> rvba: Itâs a bridge between any threaded code and the reactor.
<allenap> rvba: So if, say, a power action in pserv needs to use RPC, itâs find to use crochet.run_in_reactor, say.
<allenap> s/find/fine/
<rvba> allenap: so: reactor â threaded code using deferToThread and to talk *back* you can use crochet?
<rvba> allenap: back to the point, why did you say this shouldn't be in pserv?  I really don't understand.
<allenap> rvba: I saw âUnhandled error in EventualResultâ in pserv.log. EventualResult is part of crochet. But send_event_node must clearly be run in the reactorâ¦ if itâs run outside of the reactor the `yield client(â¦)` bits would be returning EventualResult objects, which inlineCallbacks doesnât recognise and wouldnât wait for; it would then proceed
<allenap> straight onto the next `yield client(â¦)`. At that point thereâs a race.
<rvba> allenap: okay, I misunderstood what you said.  To me, "not in pserv" means "not in the cluster", i.e. in the region.
<allenap> rvba: In other words, both of those client(â¦) calls in send_event_node would be called in very quick succession, and nothing would be waiting for the first (or the second) call to complete.
<rvba> allenap: yeah, I get it now.
<allenap> rvba: Cool. I donât mind fixing it, unless youâre desperate to do it?
<allenap> gmb: Iâm going to have a quick lunch. Want to talk right after that?
<rvba> allenap: You already have a diff, I'll test itâ¦ maybe you can put the branch together in the meantime.
<allenap> rvba: Okay. I hope the diff fixes it :)
 * allenap goes for lunch
<gmb> allenap: Iâm free from now until ~14:15, then Iâm getting on a train, so whatever works for you :)
<rvba> allenap: looks like your diff fixes the problem.
<allenap> rvba: \o/
<allenap> rvba: Want to review it? :) https://code.launchpad.net/~allenap/maas/rpc-power-sync-async-mix-up/+merge/234465
<rvba> allenap: nice; why don't we need run_tests_with = MAASTwistedRunTest again?
<allenap> rvba: The ones that use the IOPump donât touch the reactor. Some of them used that so they could return a Deferred and let the test runner figure out if there was a failure, but the Deferred had all fired so I used extract_result() to check them.
<allenap> blake_r: Are you going to resurrect your work on the report_boot_images task?
<roaksoax> allenap: he is away to day unfortunately
<allenap> roaksoax: Okay, Iâll see if I can find his work and finish it off.
<roaksoax> allenap: thanks! I see he has just one branch left!
<roaksoax> allenap: although, I'd say you should finish the update_node_tags card first though
<allenap> roaksoax: Agreed, thatâs what Iâm working on now.
<roaksoax> allenap: perfect! tha nks
<rvba> allenap: doing another round of testing now that your code has landed.
<roadmr> roaksoax: ok, it's for that provisioning project we discussed a while back. I have an ubuntu desktop image that can be installed with curtin, now I'd like to be able to select it for maas to install it on a node
<roadmr> roaksoax: I poked a bit at things and I'm not sure if I have to just drop the image somewhere in the maas server, or if I have to provide a more complex structure (simplestreams, a keyring, that stuff)
<roaksoax> roadmr: you can just drop a curtin image in MAAS, and MAAS would install it
<roaksoax> roadmr: the image would be a cloud image like, which smoser could provide more input on
<roadmr> roaksoax: oh so the image needs some metadata or extra stuff?
<roaksoax> roadmr: not really. The only thing that the image would need is just basically be like a cloud image
<roaksoax> roadmr: smoser would have a better idea of what it needs in regards to curtin/cloud-init
<roaksoax> roadmr: the thing is that once installed, cloud-init contacts the MAAS server to run final tasks
<roadmr> roaksoax: oh I see... I already tested installing my image with curtin so that part is done, I'd need to look into cloud-init
<roadmr> roaksoax: once the image is ready, where should I put it? I'm looking in /var/lib/maas/boot-resources, there's a lot of structure there so I'm wondering where it should go
<roaksoax> roadmr: I think you'd just need to have cloud-init in your image
<roaksoax> roadmr: if you are using MAAS 1.7, you would just be able to upload the image to MAAS via the CLI
<roadmr> roaksoax: oh! well I'm not, but that can be easily remedied. /me upgrades
<roadmr> roaksoax: (we get to dictate requirements, yay, so if MAAS 1.7 makes things significantly easier, we can just require that)
<roaksoax> roadmr it does. you'd just need to upload an image and that's it. I'd recommend you talk to smoser for this
<roadmr> roaksoax: I will! thanks! now let's see about upgrading this thing
<fgiraldeau> Hello! I installed MAAS, and then defined a faster deb mirror. The setting in /etc/apt/sources.list is correct, but I was getting 403 Forbidden on the Package file while doing "apt-get update"
<fgiraldeau> I had to change the setting in squid-deb-proxy, adding the new mirror in the file /etc/squid-deb-proxy/mirror-dstdomain.acl.d/10-default
<fgiraldeau> and then service squid-deb-proxy restart to solve the issue
<fgiraldeau> I think that changing the MAAS mirror setting in the web interface should add the mirror to the squid repo, otherwise it won't work
<fgiraldeau> Shall I open a bug for that?
<roadmr> roaksoax: ok, I got maas 1.7 up and running, how do I upload my image? I got maas (cli) setup and logged in. If there's a doc describing this, I'm happy to dive in and read it
<kiko> hey there
<kiko> I've got a maas install from experimental on trusty
<kiko> and I can't get boot images to load
<kiko> does anyone know a workaround for that?
 * kiko looks at blake_r and roaksoax 
<fgiraldeau> OK, well after checking, the bug about squid-deb-proxy is already reported: https://bugs.launchpad.net/maas/+bug/1300266
<ubot5> Launchpad bug 1300266 in MAAS "squid-deb-proxy returns 403 when admin configures a custom APT archive" [High,Triaged]
<roaksoax> kiko: when you click on the webui it does not download the images?
<roaksoax> kiko: try: maas admin boot-resources import
<kiko> will do
<roaksoax> kiko: and check progress wiht: maas admin boot-resource read 1 | grep progress
<kiko> oh nice
<roaksoax> kiko: all the functionality is there, we just have to make it available in the WebUI
<roaksoax> kiko: so that will donwload the images to the DB
<roaksoax> kiko: and then it will tell the clusters to import the images
#maas 2014-09-13
<jose> hello! I have some troubles deploying with Juju on MAAS, it says '409 Conflict'
<jose> any ideas?
#maas 2015-09-07
<Zeus_> hi there
<Zeus_> I have a problem when i try to get a node running in my testing enviroment. i'm trying to run a new node, but when the node starts a poweroff command is issued.  In the logs i see a message "PXE Request â power off". Any tips?
<Zeus_> I have a problem when i try to get a node running in my testing enviroment. i'm trying to run a new node, but when the node starts a poweroff command is issued.  In the logs i see a message "PXE Request â power off". Any tips?
<Zeus_> I have a problem when i try to get a node running in my testing enviroment. i'm trying to run a new node, but when the node starts a poweroff command is issued.  In the logs i see a message "PXE Request â power off". Any tips?
<Zeus_> I have a problem when i try to get a node running in my testing enviroment. i'm trying to run a new node, but when the node starts a poweroff command is issued.  In the logs i see a message "PXE Request â power off". Any tips?
<binoy> 	  Getting following error while running the the nodedev-create command.
<binoy> root@vagrant-ubuntu-trusty-64:/home/vagrant# virsh nodedev-create node.xml error: Failed to create node device from node1.xml error: internal error: Device is not a fibre channel HBA
<binoy>  have any idea regarding this
<mup> Bug #1493137 opened: 2nd interface eth1 is down on deployed server <MAAS:New> <https://launchpad.net/bugs/1493137>
#maas 2015-09-08
<mup> Bug #1311700 changed: "Setting oauth clockskew" messages on booting node; slows down boot <cloud-init:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1311700>
<mup> Bug #1311700 opened: "Setting oauth clockskew" messages on booting node; slows down boot <cloud-init:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1311700>
<mup> Bug #1311700 changed: "Setting oauth clockskew" messages on booting node; slows down boot <cloud-init:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1311700>
<mup> Bug #1382196 changed: Changing IP address for the region causes the cluster to ignore pserv.conf and endlessly respawn <MAAS:Won't Fix> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1382196>
<mup> Bug #1382196 opened: Changing IP address for the region causes the cluster to ignore pserv.conf and endlessly respawn <MAAS:Won't Fix> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1382196>
<mwenning> Hi MAAS team:  is there a way to fetch the XML for the Commissioning Summary for each node in MAAS?
<mup> Bug #1382196 changed: Changing IP address for the region causes the cluster to ignore pserv.conf and endlessly respawn <MAAS:Won't Fix> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1382196>
<mup> Bug #1382196 opened: Changing IP address for the region causes the cluster to ignore pserv.conf and endlessly respawn <MAAS:Won't Fix> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1382196>
<mup> Bug #1382196 changed: Changing IP address for the region causes the cluster to ignore pserv.conf and endlessly respawn <MAAS:Won't Fix> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1382196>
<mup> Bug #1441497 changed: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mup> Bug #1441497 opened: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mup> Bug #1441497 changed: DNS in deployed nodes not set correctly <MAAS:New> <https://launchpad.net/bugs/1441497>
<mwenning> Hi MAAS team:  is there a way to fetch the XML for the Commissioning Summary for each node in MAAS?
<blake_r> mwenning: maas my-maas-session node details node_system_id
<tehx> Hi
<tehx> I wanna discuss something about maas install, someone interested?
<mwenning> blake_r, thanks!!  I'll give it a try
<jbran_> Hi
<jbran> Is there a way for me to deploy a specific point release using MAAS? What determines what point release gets installed?
<jbran> My applications depend on very specific library/kernel versions and I need to deploy 14.04.0 consistently but MAAS seems to want to always deploy the latest, 14.04.5
<jbran> err 14.04.2
#maas 2015-09-09
<jbran> Is there any documentation on creating my own image?
<jbran> Let me rephrase that. To me it seems that boot images are being placed in /var/lib/maas/boot-resources/current/ubuntu/amd64/generic/trusty/release and I would like to try making my own custom boot image. Is there anything that describes the format/conventions or what I need at a minimum in that image?
<mup> Bug #1493646 opened: clusterd error: Port' object has no attribute 'socket' <landscape> <MAAS:New> <https://launchpad.net/bugs/1493646>
<mup> Bug #1493646 changed: clusterd error: Port' object has no attribute 'socket' <landscape> <MAAS:New> <https://launchpad.net/bugs/1493646>
<mup> Bug #1493646 opened: clusterd error: Port' object has no attribute 'socket' <landscape> <MAAS:New> <https://launchpad.net/bugs/1493646>
<mup> Bug #1493646 changed: clusterd error: Port' object has no attribute 'socket' <landscape> <MAAS:New> <https://launchpad.net/bugs/1493646>
<sky1981> set mode +v @sky1981 +kb
<sky1981> *lea(v)fes* -.-
<jbran> Anyone around?
<mup> Bug #1465736 changed: 1.8.0 Actions design styles  <MAAS:New for ricgard> <https://launchpad.net/bugs/1465736>
<mup> Bug #1465736 opened: 1.8.0 Actions design styles  <MAAS:New for ricgard> <https://launchpad.net/bugs/1465736>
<mup> Bug #1465736 changed: 1.8.0 Actions design styles  <MAAS:New for ricgard> <https://launchpad.net/bugs/1465736>
<mup> Bug #1465736 opened: 1.8.0 Actions design styles  <MAAS:New for ricgard> <https://launchpad.net/bugs/1465736>
<mup> Bug #1465736 changed: 1.8.0 Actions design styles  <MAAS:New for ricgard> <https://launchpad.net/bugs/1465736>
<ejat> hi ... im trying MAAS using vm ... managed to get the node pxe boot .. but end up cc_final_message.py[WARNING]: Used fallback datasource
<ejat> anyone ?
#maas 2015-09-10
<mup> Bug #1494161 opened: clusterd.log tftp entries should give files, machine names and IP addresses <MAAS:New> <https://launchpad.net/bugs/1494161>
<mup> Bug #1494161 changed: clusterd.log tftp entries should give files, machine names and IP addresses <MAAS:New> <https://launchpad.net/bugs/1494161>
<mup> Bug #1494161 opened: clusterd.log tftp entries should give files, machine names and IP addresses <MAAS:New> <https://launchpad.net/bugs/1494161>
<mgz> allenap: bug 1433275
<mup> Bug #1494439 opened: 1.9.0 Error grabbing cluster configuration lock causes importing to fail. <MAAS:Triaged by allenap> <https://launchpad.net/bugs/1494439>
<mup> Bug #1494449 opened: [1.9] get_release_num exceptions.IndexError: string index out of range <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1494449>
<mup> Bug #1494465 opened: Claiming mutliple AUTO IP address on a node causes serialization error <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494465>
<mup> Bug #1494465 changed: Claiming mutliple AUTO IP address on a node causes serialization error <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494465>
<mup> Bug #1494465 opened: Claiming mutliple AUTO IP address on a node causes serialization error <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494465>
<mup> Bug #1494472 opened: Linking more than one subnet with a gateway_ip causes the node not to bring up networking <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494472>
<mup> Bug #1494472 changed: Linking more than one subnet with a gateway_ip causes the node not to bring up networking <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494472>
<mup> Bug #1494472 opened: Linking more than one subnet with a gateway_ip causes the node not to bring up networking <networking> <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1494472>
<mup> Bug # changed: 1358130, 1395896, 1403497, 1407650, 1415466, 1418173
<mup> Bug #1494483 opened: Filter usage feels confusing <MAAS:New> <https://launchpad.net/bugs/1494483>
<mup> Bug #1494483 changed: Filter usage feels confusing <MAAS:New> <https://launchpad.net/bugs/1494483>
<mup> Bug # opened: 1358130, 1395896, 1403497, 1407650, 1415466, 1418173
<mup> Bug # changed: 1358130, 1395896, 1403497, 1407650, 1415466, 1418173
<mup> Bug #1494483 opened: Filter usage feels confusing <ui> <ux> <MAAS:New for carlaberkers> <https://launchpad.net/bugs/1494483>
<mup> Bug #1399377 changed: maas.log shows output that is not user friendly. <dns> <log> <MAAS:Invalid> <https://launchpad.net/bugs/1399377>
<mup> Bug #1482441 changed: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482441>
<mup> Bug #1399377 opened: maas.log shows output that is not user friendly. <dns> <log> <MAAS:Invalid> <https://launchpad.net/bugs/1399377>
<mup> Bug #1482441 opened: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482441>
<mup> Bug #1399377 changed: maas.log shows output that is not user friendly. <dns> <log> <MAAS:Invalid> <https://launchpad.net/bugs/1399377>
<mup> Bug #1482441 changed: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482441>
<mup> Bug #1399377 opened: maas.log shows output that is not user friendly. <dns> <log> <MAAS:Invalid> <https://launchpad.net/bugs/1399377>
<mup> Bug #1482441 opened: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482441>
<mup> Bug #1399377 changed: maas.log shows output that is not user friendly. <dns> <log> <MAAS:Invalid> <https://launchpad.net/bugs/1399377>
<mup> Bug #1482441 changed: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482441>
<mup> Bug #1054520 changed: UI refers to "Release" instead of "Series" <tech-debt> <MAAS:Invalid> <https://launchpad.net/bugs/1054520>
<mup> Bug #1054520 opened: UI refers to "Release" instead of "Series" <tech-debt> <MAAS:Invalid> <https://launchpad.net/bugs/1054520>
<mup> Bug #1054520 changed: UI refers to "Release" instead of "Series" <tech-debt> <MAAS:Invalid> <https://launchpad.net/bugs/1054520>
#maas 2015-09-11
<Kiall> Hey Folks - Does anyone have a pointer to some docs on creating custom ubuntu images? Every custom image I've tried results in ..
<Kiall> ERROR 2015-09-11 12:27:40,753 twisted {} / WARNING 2015-09-11 12:30:35,821 django.request Not Found: /MAAS/images-stream/custom/amd64/generic/vivid-test/20150911/root-tgz
<Walex> hi, I am on ULTS14.04 that is a but behind with updates, and have MAAS 1.5.4 and 1.7.6 is available. Is such an upgrade "backwards compatible"? As in an inplace-upgrade would it disturb/destroy existing configs? The setup if for 12 existing metal systems, now virtual, as a provider to Juju
<mup> Bug #1494858 opened: MAAS 1.8 reinstall fails <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1494858>
<Kiall> Hey Folks - Does anyone have a pointer to some docs on creating custom ubuntu images? Every custom image I've tried results in ..
<Kiall> ERROR 2015-09-11 12:27:40,753 twisted {} / WARNING 2015-09-11 12:30:35,821 django.request Not Found: /MAAS/images-stream/custom/amd64/generic/vivid-test/20150911/root-tgz
<Walex> http://askubuntu.com/questions/665170/python-error-during-maas-upgrade happens here when upgrading from 1.5.4 to 1.8.0, which is marked as "stable" in the PPA, but then there are several reports happen
<mup> Bug #1494858 changed: MAAS 1.8 reinstall fails <canonical-bootstack> <MAAS:Invalid> <https://launchpad.net/bugs/1494858>
<mup> Bug #1430236 changed: Switch local config from SQLite to Plain Ole Text Files jus' like my grandpappy used <MAAS:Won't Fix> <https://launchpad.net/bugs/1430236>
<mup> Bug #1430236 opened: Switch local config from SQLite to Plain Ole Text Files jus' like my grandpappy used <MAAS:Fix Committed> <https://launchpad.net/bugs/1430236>
<mup> Bug #1494955 opened: MAAS reports duplicate MAC on commissioning <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1494955>
<mup> Bug #1430236 changed: Switch local config from SQLite to Plain Ole Text Files jus' like my grandpappy used <MAAS:Fix Committed> <https://launchpad.net/bugs/1430236>
<mup> Bug #1494955 changed: MAAS reports duplicate MAC on commissioning <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1494955>
<mup> Bug #1430236 opened: Switch local config from SQLite to Plain Ole Text Files jus' like my grandpappy used <MAAS:Fix Committed> <https://launchpad.net/bugs/1430236>
<mup> Bug #1494955 opened: MAAS reports duplicate MAC on commissioning <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1494955>
#maas 2015-09-12
<mup> Bug #1495064 opened: MAAS "migrations" '0121_recompute_storage_size' fails 1.5.4 to 1.8.0 <MAAS:New> <https://launchpad.net/bugs/1495064>
#maas 2016-09-12
<koaps> roaksoax: ya, i tried that command and nothing happened, you would think that would be right
<mup> Bug #1602093 changed: [2.0r1] maas webui error updating subnet mtu when dhcp is configured <MAAS:Expired> <https://launchpad.net/bugs/1602093>
<mup> Bug #1602093 opened: [2.0r1] maas webui error updating subnet mtu when dhcp is configured <MAAS:Expired> <https://launchpad.net/bugs/1602093>
<mup> Bug #1602093 changed: [2.0r1] maas webui error updating subnet mtu when dhcp is configured <MAAS:Expired> <https://launchpad.net/bugs/1602093>
<neith> kiko: I understand I must not provide 2 default gw for maas server as well for enlisted nodes. But should I add a default gw to the public subnet? not the subnet on which nodes pxe boot
<rock_> Hi. I want to  use KVM machines for  maas setup using http://maas.io/docs/installconfig-add-nodes.  So I created one kvm machine for maas-admin node. From that machine I ran  $sudo virsh list --all. It was returning empty. Please provide me solution for this.
<roaksoax> neith: you can change the interface which will configure the default gateway
<roaksoax> neith: look into "maas <user> interface set-default-gateway"
<roaksoax> rock_: i think you have the wrong conception of what KVM/virsh do
<roaksoax> rock_: if you do: sudo virsh list --all -> that will list of KVM's VM's running on the system where you are running that command
<roaksoax> rock_: if that's a VM, it is most likely you don't have nested VM's on that machine
<roaksoax> rock_: so you need to log into a external KVM/libvirt, to be able to list running VM's
<rock_> roaksoax: Thank you. I have a question with KVM machines maas setup.
<roaksoax> rock_: so, are you running MAAS as a VM right ?
<roaksoax> rock_: so say, MAAS is in subnet 192.168.122.0/24, and your KVM host is 192.168.122.1/24 right ?
<rock_> roaksoax: Yes.
<roaksoax> rock_: so you'd need to do something like: virsh -c qemu+ssh://192.168.122.1/system list --all
<roaksoax> rock_: so you'd need to do something like: virsh -c qemu+ssh://<user>@192.168.122.1/system list --all
<rock_> roaksoax: I created one kvm machine for MAAS installation It has taken 192.168.122.98 [DHCP]
<roaksoax> rock_: right, so you need to:
<roaksoax> 1. configure you MAAS VM with static IP address
<roaksoax> 2. disable libvirt DHCP, or it wont let MAAS provide DHC{P
<rock_> roaksoax: So can I configure static IP for MAAS VM using 192.168.122.0/24 range IP.
<rock_> roaksoax: For remaining 4 maas-slave nodes, No need to install OS. Enabling pxe boot is sufficient? Then MAAS will do auto discovery ?
<rock_> roaksoax: (or) for adding nodes manually, I need power ID and adress of slave nodes right. Power ID means name of slave-node. So How can I get power address?
<roaksoax> rock_: so do 1 and 2 above, then name the VM's maas will control somthing different from MAAS< for example:
<roaksoax> maas-server, node01,node02, etc  (in livirt)
<roaksoax> rock_: 3. name your MAAS VM vs your node's differently, so they have a different prefix
<roaksoax> rock_: 4. Go to MAAS, click on 'Add Chassis', and input for power address: qemu+ssh://<user>@192.168.122.1/system power password: your psasword, prefix filter - a prefix to import all of those machines that start with that prefix (that does NOT match the MAAS server)
<roaksoax> rock_: 5. configur DHCP in MAAS
<roaksoax> rock_: 6. Download images in MAAS
<rock_> roaksoax: OK. Thank you. So I have give the same power address :qemu+ssh://<user>@192.168.122.1/system power for all slave nodes right. In MAAS node am I need to create a bridge (or) router kind of thing.
<roaksoax> rock_: no, since they are all vm's, theu will all access the internet via the KVM host machine
<roaksoax> rock_: via 192.168.122.1
<roaksoax> rock_: if you were running maas in the KVM host machine (uinstead of inside a VM), they you may need to create a bridge
<rock_> roaksoax: Ok. Thank you.
<rock_> SO in maas VM i have to take 192.168.122.1 as gateway, 192.168.122.0/24 as network , and 255.255.255.0 as netmask and address as 192.168.122.x right.
<rock_> roaksoax: And have to make the given IP as static.
<rock_> roaksoax: Thank you for your patience in providing the detailed answers..
<neith> roaksoax: How can I remove the default gateway??
<PCdude> kiko: hÃ© again, I had alot of work in the last couple of days, but gonna try and troubleshoot again :) . My question is if u know how to trim down the time that the installer fails. Right now its 3000 seconds which is enormous for troubleshooting
<roaksoax> PCdude: define trim down the installer fails ?
<roaksoax> neith: don't put a gateway int he subnet, but why would you want to do that ? machines wouldn't be able to install packages and such without it
<PCdude> roaksoax: good point, I am trying to install openstack with "openstack-installer". I am using the autopilot option in there. It fails and I have had some good help a couple of days ago from different people on IRC. I am wanna try to troubleshoot some more, but the installer fail takes 3000 seconds. There should be a file somewhere on the disk that
<PCdude> defines that number. I wanna change that so I can troubleshoot faster and see what changes in the error log.
<PCdude> roaksoax: does that make sense?
<roaksoax> PCdude: it does, the 3000 seconds though seems to be a timeout someone else holds that it is not MAAS
<roaksoax> PCdude: MAAS has a 40 minute deployment timeout, where if the machine has not been deployed in 40 minutes, it gets marked as failed deployment
<roaksoax> PCdude: and that is non-configurable in MAAs
<roaksoax> PCdude: that said, when deploying opestanck you may want to identify two things:
<roaksoax> 1. MAAS 2. Juju.
<roaksoax> 1. does MAAS mark the amchine deployed ? IF it does, then JUju (or something else) cases the machjine to have  failed in Juju)
<PCdude> roaksoax: it is know where the issue is. JUJU is staring an container on a node, but either is communicating wrong or LXC is giving no IP to the container. Which makes that the container cannot be reached. The problem is that I want to try some things out, but yeah that is gonna take me all day. The reason I asked kiko was simply coz I spoke about
<PCdude> this a reasonable amount. So maybe he knew, but I am aware of the fact that this is not MAAS related.
<sgoller> Hey all, I'm trying to deploy maas-2.0 and I'm running into problems. I have a region controller and a rack controller on separate boxes. The rack controller is registered, but when I try to provide dhcp for its subnet, the region controller has an empty list for the rack controller.
<sgoller> Any ideas?
<kiko> sgoller, seems like a bug. 2.0 final?
<kiko> sgoller, basically you registered the cluster controller with the region and it doesn't show up?
<kiko> sgoller, or perhaps are you missing the registration step?
<sgoller> the steps I took were:
<sgoller> installed region controller
<sgoller> made sure it could be logged into
<sgoller> installed the rack controller
<sgoller> registered it with the region controller
<kiko> and the registration succeeded?
<sgoller> yes
<sgoller> the subnet for the rack controller is present
<kiko> roaksoax, ^^ what do you think?
<sgoller> I created a separate fabric for the subnet, moved the rack controller's subnet over
<sgoller> then went to the untagged vlan for that fabric and selected "provide dhcp"
<sgoller> the subnet shows up fine, but the list of rack controllers is empty.
<sgoller> MAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1)
<sgoller> is there a newer version? I'm pulling from ppa:maas/stable
<sgoller> i'm going to blow everything away and start from scratch
<kiko> sgoller, that's the right version
<kiko> sgoller, let me get somebody to help before you blow it away
<sgoller> kiko, ok.
<kiko> sgoller, does anything show up in your /var/log/maas or syslog?
<kiko> sgoller, anything suggesting a problem?
<sgoller> not seeing anything obvious. I'm going to go through provide dhcp again to see if something shows up
<sgoller> Sep 12 11:21:23 maas-region sh[3771]: 2016-09-12 11:21:23 [HTTPChannel,20,127.0.0.1] Opening connection with IPv4Address(TCP, '127.0.0.1', 54928) Sep 12 11:21:23 maas-region sh[3771]: 2016-09-12 11:21:23 [-] Closing connection: <STATUSES=PROTOCOL_ERROR> ('Failed to authenticate user.')
<sgoller> this shows up periodically
<sgoller> on the region controller
<sgoller> here's more
<sgoller> Sep 12 11:22:37 maas-region sh[3771]: 2016-09-12 11:22:37 [-] 127.0.0.1 - - [12/Sep/2016:18:22:36 +0000] "GET /MAAS/rpc/ HTTP/1.1" 200 220 "-" "provisioningserver.rpc.clusterservice.ClusterClientService" Sep 12 11:22:41 maas-region sh[3771]: 2016-09-12 11:22:41 [HTTPChannel,23,127.0.0.1] Opening connection with IPv4Address(TCP, '127.0.0.1', 55068) Sep 12 11:22:41 maas-region sh[3771]: 2016-09-12 11:22:41 [-] Closing connection: <STATUSES
<sgoller> WAT
<sgoller> ok, now it's shown up
<kiko> mpontillo, ^^
<kiko> sgoller, did you change anything?
<sgoller> I had shutdown both the rack controller and the region controller
<sgoller> because i was going to reinstall them
<sgoller> but then on your suggestion I brought them back up
<sgoller> ugh.
<kiko> sgoller, I'm wondering what you changed beyond restarting things that made it function
<koaps> sgoller: think I've seen something like that before when I played with 2.0 beta a while back
<koaps> I had to restart the dhcp service
<sgoller> koaps: hm. This was a fresh install, and no dhcp had been configured yet, so it wasn't running at all on the rack controller. It's running now, however, since I was able to provision that subnet.
<koaps> I've been meaning to setup my dev env with 2.0, if I get a chance I'll do that an maybe file a bug if I get same behavior, or look for yours :)
<kiko> sgoller, what did you do exactly to register the controller?
<kiko> sgoller, I'm wondering if you changed anything else after that and before restarting
<sgoller> i clicked on add rack controller, which outputs a series of commands
<sgoller> like i said, i moved the subnet connected to the rack controller over to fabric-1.
<sgoller> maybe something to do with that
<sgoller> and i had moved it back but it still had a problem
<sgoller> so i suspect there may be some issue there.
<sgoller> the rack controller is having problems syncing images with the region controller, so I think i'm going to reinstall again anyway.
<sgoller> kiko, thanks for your help.
<kiko> sgoller, wait, don't reinstall :)
<kiko> sgoller, what issues are happening? let's look at the logfiles?
<kiko> sgoller, I think you hit an underlying bug I'd love to figure out
<sgoller> sorry, I already reinstalled. :(
<kiko> sgoller, okay, let's keep an eye out if the problem reoccurs
<sgoller> kiko, for sure. I'm going to follow the same steps.
<sgoller> kiko, ok, I'm in that exact same scenario now. The order of operations was: Install region controller. create account, login to make sure it was up. install rack controller software, use add rack controller in the ui to show the commands to run to register it. register rack controller via cli...
<sgoller> kiko, then move the rack controller's subnet to a different fabric
<sgoller> then go to the untagged vlan on the new fabric, and select "Provide DHCP". The following screen does not have a selectable rack controller.
<sgoller> kiko, so this is reproducible
<kiko> sgoller, same log entry? and if you restart rackd, does it work?
<sgoller> so this is interesting.
<sgoller> going to the node page for the rack controller
<sgoller> it lists it as being the rack controller for things only connected to the region controller
<sgoller> kiko, this seems to imply that maas really doesn't like a standalone region controller
<sgoller> kiko, the region controller has associated the subnets that are attached to itself to the rack controller, which is on a completely separate network.
<kiko> sgoller, I think it's actually that registration is failing
<kiko> but I'm not sure why
<kiko> which is why I'm keen on the logs
<sgoller> what logs would you like? /var/log/syslog from the rack controller?
<kiko> sgoller, /var/log/maas actually
<sgoller> hm. you can't upload a file to pastebin? weak.
<kiko> sgoller, you can pipe to pastebinit!
<sgoller> kiko, got it, thanks!
<roaksoax> sgoller: sudo pastebinit /var/log/maas/rackd.log , and that for maas.log and regiond.log
<PCdude> kiko: https://www.reddit.com/r/homelab/comments/4p3k9j/trouble_getting_lxc_networking_up_containers_not/
<PCdude> kiko: no time tonight, but maybe the solution to my problem
<mup> Bug #1565467 opened: twistd3 crashed with PermissionError in touch(): [Errno 13] Permission denied: '/etc/maas/rackd.conf' <amd64> <apport-crash> <xenial> <MAAS:Confirmed> <twisted (Ubuntu):Expired> <https://launchpad.net/bugs/1565467>
<mup> Bug #1565467 changed: twistd3 crashed with PermissionError in touch(): [Errno 13] Permission denied: '/etc/maas/rackd.conf' <amd64> <apport-crash> <xenial> <MAAS:Confirmed> <twisted (Ubuntu):Expired> <https://launchpad.net/bugs/1565467>
<mup> Bug #1565467 opened: twistd3 crashed with PermissionError in touch(): [Errno 13] Permission denied: '/etc/maas/rackd.conf' <amd64> <apport-crash> <xenial> <MAAS:Confirmed> <twisted (Ubuntu):Expired> <https://launchpad.net/bugs/1565467>
<kv> just wonder if maas 2 works with juju 2  yet ?
<kiko> kv, yes, though juju2 is not final yet -- still a beta
<kiko> kv, I hear the next release is an RC now!
<kv> so the combo maas 2, juju 2, and conjure-up should work?
<kiko> yes
<kiko> and stokachu and mmcc are here to ensure conjure-up does ;)
<kv> cool... i am going to give it another shot
<jwitko> Hey guys, I just installed the latest stable 2.0 release and although I have imported ubuntu 16.04 and 14.04 images I still can not add any bare metal machines (The save button is disabled).  One weird thing I've noticed is that under my settings I have no default comissing OS or deployment OS (The lists are empty except for an item telling me there are none to choose from)
<jwitko> Anyone ever seen this before?  Logs don't seem too crazy, this is a fresh install of both OS and maas, installation performed via apt
<kiko> jwitko, hmm, that's slightly odd
<kiko> jwitko, have you added SSH keys?
<kiko> jwitko, however it does look like you've run into.. a bug?
<kiko> those lists AIUI should not be empty
<kiko> have the images finished syncing completely?
<jwitko> how can I tell ?
<jwitko> But they should have, its been a long time since I selected them to be imported
<kiko> jwitko, there's UI feedback that it completed, so I'm guessing it did
<jwitko> kiko, http://paste.ubuntu.com/23171284/
<jwitko> also, un-selecting the ubuntu releases that I've imported and hitting "apply changes" does not remove the images
<kiko> jwitko, what shows up in /var/lib/maas?
<jwitko> drwxr-xr-x  2 maas maas 4096 Sep 12 14:02 gnupg
<jwitko> -rw-------  1 maas maas    6 Sep 12 15:21 maas_id
<jwitko> -rw-r--r--  1 maas maas 1689 Sep 12 15:21 maas-proxy.conf
<jwitko> -rw-r-----  1 maas maas   32 Sep 12 14:02 secret
<kiko> okay
<kiko> jwitko, and anything suspicious /var/log/maas?
<jwitko> maas.log:Sep 12 15:18:23 maas1 maas.bootresources: [WARNING] Unable to import boot images, no image descriptions avaliable.
<roaksoax> jwitko: do you have a console log for the machine or /var/log/maas/rsyslog/maas-enlisting-node/* or /var/log/maas/rsyslog/<machine-name>/*
<roaksoax> jwitko: i dont think you are running into issue
<roaksoax> i think you are running into a bug with the kernel
<jwitko> http://paste.ubuntu.com/23171298/
<jwitko> I'm running into a bug with the kernel... on the stable 2.0 release..  on a stock 16.04 fully updated install ?
<kiko> regiond.log:2016-09-12 14:22:25 [-] Error on request (2428) controller.check_images: 4y3h7p
<kiko> regiond.log:        raise HandlerDoesNotExistError(pk)
<kiko> regiond.log:    maasserver.websockets.base.HandlerDoesNotExistError: 4y3h7p
<jwitko> kiko,  all errors, crits, warns, fails from the logs:   http://paste.ubuntu.com/23171298/
<jwitko> oh you sa
<jwitko> w
<kiko> roaksoax?
<roaksoax> jwitko: ah! yes, so no your bug is not what I was thinking about then
<jwitko> have to let the dog out,  brb in 5m
<roaksoax> jwitko: can you pastebin all of rackd.log and regiond.log ?
<jwitko> roaksoax, sure
<jwitko> roaksoax, there is no rackd.log ?
<jwitko> maas.log and regiond.log
<mup> Bug #1622770 opened: [2.1, vanilla] Can't select CentOS images <ui> <ux> <vanilla> <MAAS:New> <https://launchpad.net/bugs/1622770>
<jwitko> roaksoax, here is maas.log
<jwitko> http://paste.ubuntu.com/23171341/
<jwitko> and here is regiond.log  http://paste.ubuntu.com/23171343/
<roaksoax> jwitko: rackd.log ?
<jwitko> roaksoax, I said above there is no rackd.log in /var/log/maas
<roaksoax> jwitko: ok, so it seems you dont have a rack controller
<roaksoax> jwitko: on this machine
<roaksoax> jwitko: dpkg -l | grep maas
<jwitko> lol are you serious
<jwitko> this asshole
<jwitko> (the guy who installed it)
<jwitko> so a rack controller is the updated name for a 'cluster controller' ?
<roaksoax> jwitko: yes, the internals are completely different but yes
<jwitko> ty
<newtomaas> Hi all - very new to maas and having trouble with pxe boots appearing not to do what they are meant to.. i see errors where it is trying to hit the 169.x.x.x subnet and many time outs and eventually it will land at an ubuntu prompt. running maas on physical hardware ubuntu 16 lts. also pxe boots are very unreliable. Machines trying to enlist are VMs.
<kv> Unable to connect to: ws://xx.x.x.x/MAAS/ws
<kv> any idea why I am getting that error kiko?
<kv> a brand new setup...maas 2.0.0+bzr5189-0ubuntu1~16.04.1
<kv> i see what is going on..it's listening on 5240 by default
<mup> Bug #1622786 opened: [2.0] Error "could not terminate the child" on node UI page above power parameters <oil> <MAAS:New> <https://launchpad.net/bugs/1622786>
#maas 2016-09-13
<kv> conjure-up 2 and juju 2 are still no luck
<kv> http://paste.ubuntu.com/23171693/
<ArturasR> Hello, I have asked question in maas devel mailing list about ability to have software raid solution with non ubuntu images, and Christian recommended to ask it here. Well, I'm looking for a way, how to tell maas to use software raid devices as TARGET, instead of simple disk. It's available with ubuntu by default, but it's disabled for other distros. builtin: [curtin, block-meta, simple] - as I understood, I should somehow pass 'custom' to that place, instea
<neith> roaksoax: because I have 2 nic , each one on a different subnet. The subnet used to pxe boot and the 'public' from which hosts are reachable from the rest of the network. My assumption is that I only need a default GW on the public network.
<Guest75192> Hi All, I am trying to install Ubuntu 12.04 image on a node and my MAAS version is 2.0 , but after around 40 minutes deployment fails giving timeout error message
<Guest75192> nothing appears in the logs
<Guest75192> did someone try Ubuntu 12.04 image deployment?
<Guest75192> any ideas or thoughts on how I can troubleshoot?
<KpuCko> My experiance says maas 2.0 is in very active development state, so for me this is running very unstable.
<KpuCko> I've installed ubuntu 16.04 lts with maas 2.0 and try to deploy node with ubuntu 16.04 - same problem like you, just failed to deploy
<KpuCko> After that i've switched to 14.04 and everyting was fine. I mean 14.04 maas node, and deploy nodes only the same version of ubuntu.
<KpuCko> maas is 1.6 i think, default with the 14.04 lts ubuntu from repositories
<mup> Bug #1622971 opened: controllers do not load on nodes page <MAAS:New> <https://launchpad.net/bugs/1622971>
<mup> Bug #1623027 opened: [2.1] MAAS should not allow user to select releases that are EOL <MAAS:New> <https://launchpad.net/bugs/1623027>
<mup> Bug #1623027 changed: [2.1] MAAS should not allow user to select releases that are EOL <MAAS:New> <https://launchpad.net/bugs/1623027>
<mup> Bug #1623027 opened: [2.1] MAAS should not allow user to select releases that are EOL <MAAS:New> <https://launchpad.net/bugs/1623027>
<rock> roaksoax : Hi. As you said yesterday, I am trying to setup maas on KVM machines. Facing issue while setting initially maas slave nodes with PXE boot. Issue details : http://paste.openstack.org/show/573609/. I request you please provide me the solution for this. I tried to solve this. But Still I am getting the same issue.
<kiko> rock, it's unclear for me -- are your KVM nodes PXE-booting successfully?
<rock> Kiko: No. While creating KVM machine[maas slave node] only I have choosen PXE boot . But It was showing "Network selection does not Support PXE".
<kiko> rock, I think you need to fix that first
<kiko> rock, what do you mean by "slave nodes"?
<rock> Kiko: mass nodes.
<kiko> rock, VMs which you want MAAS to install Ubuntu on?
<roaksoax> rock: that's a strange error, seems related to libvirt/kvm
<roaksoax> rock: so your VM's are telling you that they cannot PXE boot ?
<roaksoax> i wonder if this is with the VM/libvirt configuration itself
<rock> roaksoax: Yes.
<roaksoax> rock: how does your libvirt network config look like ? mine looks like: http://pastebin.ubuntu.com/23173664/
<rock> roaksoax: Mine also similar to your config. http://paste.openstack.org/show/573617/
<roaksoax> strange
<rock> roaksoax: Is there any other way to do. Actually I don't have enough machines to test my JUJU bundle. So I have to test that on [MAAS+OpenStack base bundle] setup.
<roaksoax> rock: what if you try to get your config look more like mine ?
<roaksoax> rock: honestly i'm quite surprised that libvirt would tell you that when the network seems to be configured correctly
<roaksoax> rock: that config above I showed you is proven to work
<rock> roaksoax: Hi. Exactly I did as shown here. http://paste.openstack.org/show/573619/.
<roaksoax> rock: do you have a screenshot of the VM config or what the VM tells you that cannot PXE boot ?
<rock> roaksoax: Yes. How can I send screeshot  through chat. please tell me
<roaksoax> rock: https://imagebin.ca/
<rock> roaksoax: Sorry for the late. https://imagebin.ca/v/2uwUL9uVDXEY.
<rock> roaksoax: https://imagebin.ca/v/2uwUpRacX3D9
<roaksoax> rock: i think that should be ok because libvirt is not providing PXE, hence it is hoswing you the message
<roaksoax> rock: what I dont understanding is the bug that libvirt gives you
<roaksoax> rock: what if you create a new one with selecting it to be PXE
<rock> roaksoax: So Is there a bit other way of doing this?.
<rock> roaksoax: (or) What are the other possible ways to do MAAS setup on Virtual machines. If we have please provide me detailed info for that.
<roaksoax> rock: no, you will have to create your own VM's for MAAS to manage them
<roaksoax> need to step out for a bit
<rock> roaksoax: OK. Thank you. MAAS can manage VBox VMs?
<rock> roaksoax: (or) MAAS can Manage VMware VMs?
<rock> If it can manages VBox VMs (or) VMWare VMs , What power types it will genarally take?
<rock> roaksoax: SO How can we configure network for those setups. Is there any specific docs for that. If you have any idea please provide me the Info.
<mup> Bug #1623110 opened: Networks page doesn't load fully on yakkety <MAAS:New> <https://launchpad.net/bugs/1623110>
<mup> Bug #1518414 opened: NVMe model info/serial number is not seen <MAAS:Incomplete> <https://launchpad.net/bugs/1518414>
<valeech> Congrats MAAS team on the 2.0 stable release! Itâs been a fun process to follow along.
<kv> hi roaksoax
<kv> are you around?
<kv> http://paste.ubuntu.com/23171693/ i am getting this error on the latest conjure-up
<baldpope> sup peeps - couple of questions about maas setup
<kiko> hey baldpope
<kiko> nice netsplit
<baldpope> in the quick-install documentation from ubuntu, the documentation implies that booting a new host will have that box show up in the list of nodes
<baldpope> but I've had to manually add nodes, is that normal?
<baldpope> sup kiko
<kiko> yes, it will if auto-enlistment succeeds
<baldpope> so then I should assume auto-enlist is failing?
<kiko> yes, it is
<baldpope> what would cause auto-enlist to fail?
<kiko> well
<baldpope> the setup instructions are pretty simple - I don't think I missed anything
<kiko> baldpope, does the host PXE-boot correctly from MAAS?
<baldpope> yes
<baldpope> well - best I can tell
<kiko> and what happens after it boots?
<baldpope> ubuntu appears to be running via iscsi back to the maas host?
<kiko> yep
<kiko> that's very much correct
<kiko> it's an ephemeral environment
<kiko> read-only iscsi
<kiko> okay
<kiko> and then?
<baldpope> does not appear to be an 'and then' just sitting at a login prompt
<baldpope> maas still shows commissioning
<kiko> hang on
<kiko> commissioning?
<baldpope> yea
<kiko> that doesn't make sense
<kiko> the first time you pxe-boot a node
<baldpope> apologies - let me start over
<kiko> :)
<baldpope> if I do nothing (after setting up maas)
<baldpope> and I boot a new host - call it blade1
<baldpope> if I do nothing more than power on, it boots via pxe
<baldpope> goes through what appears to be a pxe boot, with an iscsi root (similar to nfs root) and then eventually will get to a traditional login prompt
<baldpope> if I review maas - maas never upates the list of nodes
<baldpope> so then if I manually add a node (same blade) - it will reboot the blade and run through the same steps - but with 'commissioning' in the status
<kiko> baldpope, it is stuck at the login prompt forever?
<kiko> never shut downs?
<kiko> err shuts down?
<kiko> okay
<kiko> so yes
<kiko> something in the ephemeral environment is getting stuck
<baldpope> well - admittedly, not watching it like a hawk - possible I missed a reboot
<baldpope> but yea - appers to just sit there
<kiko> it won't reboot
<kiko> but it will shut down if it was successful
<baldpope> ah
<kiko> if it's not, it's not successful
<kiko> can you ssh in with ubuntu:ubuntu?
<baldpope> no, I don't think it's powered down
<kiko> cool
<baldpope> 1sec
<kiko> roaksoax told me that's supposed to work but I've never seen it in action
<baldpope> cannot ssh in - publickey only auth
<baldpope> and stupid me I didn't define a public key at the time
<baldpope> i do have a public key defined now - but was not at the time of initial power on / deploy
<kiko> hmmm
<baldpope> side note - supermicro ipmi/ikvm not working for me very well - so I lose console access as soon as the frame buffer kicks in - no more SoL
<kiko> baldpope, are you talking about enlistment and commissioning
<kiko> during enlistment I think we do enable passwords
<baldpope> well .. i would assume enlistment is a stage 1 and commissioning a stage 2?.. if that's the case then stage1 never occurs and stage 2 is reporting 'failed commissioning' after some number of minutes
<baldpope> that's assuming enlistment is automatic (based on pxe boot of a clean / new host)
<baldpope> and at the moment, it appears that the host is just sitting at a console login screen
<kkkkk> hey kilo, is it okay to install maas 2.0, and conjure-up 2.0, juju 2.0 on the same box?
<baldpope> kiko, we lose you bud?
<baldpope> when booting up -there is a config element that shows cloud-config-url=http://blah
<baldpope> but the IP listed is NOT the 'internal' IP where the new hosts sit
<baldpope> 1sec
<kkkkk> ..
<kiko> baldpope, am otp sorry :)
<baldpope> s'all good
<baldpope> just ran dpkg-reconfigure maas-cluster-controller and changed IP to internal
<baldpope> booting a node - see if that fixes it
<baldpope> looking better - it auto enlist in nodes now
<baldpope> it might be obvious - but someone might wantto clarify when running the setup to mark the controller IP as the internal address
<baldpope> wow - it even added maas as a user in the ipmi
<baldpope> slick
<kiko> mpw we
<kiko> now we're talking!
<kiko> baldpope, funny that you got caught on that one, it's such a common problem that I didn't think of asking
<baldpope> caught it by chance watching ilom - and found another user ran into similar problem
<baldpope> my mistake
<baldpope> ok, running commission now
<baldpope> btw - for reference - following http://www.ubuntu.com/download/cloud
<mup> Bug #1623192 opened: Cannot create DHCP snippet <docteam> <MAAS:New> <https://launchpad.net/bugs/1623192>
<baldpope> kiko, thanks for being a sounding board - looking good
<baldpope> first node is showing ready now
<baldpope> running through the remaining 4
<baldpope> the default node names are interesting
<baldpope> 'cooked-women'
<baldpope> that can't be good...
<baldpope> ;)
<kiko> baldpope, it was a very controversial feature implementation
<kiko> baldpope, and tbh some people have encountered rather offensive names
<baldpope> i can imagine
<kiko> but.. I kind of like them :-)
<baldpope> i can see the humor
<baldpope> but as a request - should make an option in the cluster/server config for a base name
<kiko> so that all nodes come prefixed?
<kiko> you know you can tweak everything through the API, right?
<kiko> i.e. the equivalent of a for n in get_nodes(): n.rename("us-east-"+ n.name)
<baldpope> was unaware
<kiko> everything the UI can do (and a bit more) can be driven via the API
<baldpope> is that the maas tool?
<kiko> the maas tool is a (somewhat clunky) API client
<baldpope> there are likely several bits I need to read up ... like how to configure the the nics as bonded
<kiko> yep, see maas.io/docs
<baldpope> cool - ty
<baldpope> heh - impractical clocks
<baldpope> very...
<kiko> okay, I need to split for tonight
<kiko> will see you tomorrow?
 * kiko waves out
<baldpope> later kiko
<baldpope> likely hit the channel up some more later/tomorrow
<baldpope> ugh..
 * baldpope sigh
<baldpope> had to kill openstack-install - and now I cannot run it again, openstack-install -u fails...
<baldpope> how to manually clean up openstack-install?
<mup> Bug #1623266 opened: [web UI] Proxy is for APT only <docteam> <MAAS:New> <https://launchpad.net/bugs/1623266>
#maas 2016-09-14
<roaksoax> /win/win 6
<baldpope> if I want to delete and then provision from scratch an existing node, do I release it through the webui or ?
<baldpope> appears to be to release and then commision?
<baldpope> is it possible to have video output of the boot image changed back to 80x25 - would make working with serial consoles a lot easier
<baldpope> ok, nearly 1am - misc. problems trying to deploy openstack via maas
<baldpope> anyone interested in helping out trying to get openstack pushed ?
<jwitko> hey guys when querying the maas API with python 2.7 I get an error surrounding a pickle object `ValueError: unsupported pickle protocol: 3`
<jwitko> can anyone tell me where the picke dump is being done so that I might test adding the protocol=2 parameter ?
<mup> Bug #1623468 opened: NVME disks are not showing up in MaaS when commissioning nodes using any newer kernel than "hwe-t" <MAAS:New> <https://launchpad.net/bugs/1623468>
<mup> Bug #1623468 changed: NVME disks are not showing up in MaaS when commissioning nodes using any newer kernel than "hwe-t" <MAAS:New> <https://launchpad.net/bugs/1623468>
<rock> roaksoax: Hi. Libvirt error : connection closed issue resolved. we faced the similar bug as https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/994476. Now  created 4 maas nodes with PXE boot enable option 1) add chassis https://imagebin.ca/v/2v3Cvi0gPkCG 2) enlisting nodes  https://imagebin.ca/v/2v3CKF6k90lB. After enlisting the power state not changing form on to OFF. Log info: http://paste.openstack.org/show/576163/
<rock> roaksoax: SO then I deleted enlisted nodes. Again I clicked on "Add Chassis" entered details. This nodes enlisted in MAAS UI with power state OFF.
<roaksoax> rock: that is fine
<roaksoax> rock: that is expected
<roaksoax> rock: the machines will be in "New" state and powered off
<roaksoax> rock: now you need to "Commission" them
<rock> roaksoax: Yes. I am doing now.
<rock> roaksoax: nodes state after 15 min of commissioning start https://imagebin.ca/v/2v3JgORVid5I. Two nodes came to ready state but disks not detected. power is in "on" mode. Two nodes are still commissioning . I am stucking here. IThe state of nodes not changing.
<rock> roaksoax: maas log : http://paste.openstack.org/show/576181/
<roaksoax> rock: what type of disks your VM's have?
<roaksoax> virtio ?
<rock> roaksoax:  default disk, One SATA disk[second disk]
<rock> roaksoax:  I mean One virtual disk [Disk1], second SATA disk [Disk2]
<rock> roaksoax: Genarally, what type of disks we need to take and what storage format we need to choose for KVM VMs
<rock> roaksoax: Two nodes commissioning failed with Node marking failed : timeout issue.  maas log info: http://paste.openstack.org/show/576191/
<rock> roaksoax: https://imagebin.ca/v/2v3V5ZDsIGAi.
<roaksoax> rock: there may be a bug discovering those
<roaksoax> rock: try setting the VM disk to IDE ?
<jwitko> hey guys when querying the maas API with python 2.7 I get an error surrounding a pickle object `ValueError: unsupported pickle protocol: 3`
<jwitko> can anyone tell me where the picke dump is being done so that I might test adding the protocol=2 parameter ?
<baldpope> trying to deploy openstack auto deploy with openstack-install and selecting auto deploy
<rock> roaksoax: OK. Thank you. I will try with IDE.  And In which cases we will get ERROR:  Marking node failed: Node operation 'Commissioning' timed out after 0:20:00.
<rock> roaksoax: I selected IDE disks for KVM VMs. Still two nodes not detecting disks.And two nodes are failing commission with ERROR:  Marking node failed: Node operation 'Commissioning' timed out after 0:20:00. How can I resolve this. Have you faced similar issues?.
<rock> roaksoax: In MAAS UI, clicked on "Add Machine". And then added individual machines. Here also commissioning failed: RROR:  Marking node failed: Node operation 'Commissioning' timed out after 0:20:00. For three individually added nodes it was showing the same issues.
<baldpope> rock, one thing that caught me yesterday (new maas user myself) was to make sure I was selecting the 'internal' ip of the maas server
<baldpope> in my case - two nics, one dedicated for provisioning (eth1) and the other is the lan (eth0)
<baldpope> when I setup maas, I mistakenly gave the web interface the eth0 IP
<baldpope> fixed a couple of issues once I used the correct internal ip
<baldpope> may only be an issue if you have 2 nics and the networks are firewalled between the two
<rock> baldpope: Hi. are you doing maas setup on KVM machines?
<baldpope> no, bare metal
<baldpope> or trying to
<baldpope> deploying an openstack cluster in house
<rock> baldpope: Ok. Actually, I am trying maas setup on KVM machines. I want to have [MAAS+OpenStack base bundle] setup to test our bundle.
<baldpope> sounds like we're doing much the same thing
<baldpope> i'm just on BM
<rock> baldpope: Oh. great. Previously, I setup Ubuntu Openstack Autopilot Setup On Bare Metal. Due to lack of enough servers I am going to have [MAAS+OpenStack base]  setup On KVM machines.
<baldpope> very cool rock - might have to pick your brain then
<baldpope> been running into problems attempting to run the openstack installer
<rock> baldpope: SO which problems are you facing. JUJU bootstrap error (or) LAndscape deployment error.
<baldpope> juju
<rock> baldpope: How much time it was taking to bootstrap.
<baldpope> a good 20 minutes - maybe longer
<baldpope> annoying as fuck
<jwitko> Is it possible to use python 2.7 with MaaS 2.0 API ?  it does not seem to be possible unless I'm missing something ?
<roaksoax> jwitko: 2.0 no, 2.0 doens't support py2.7
<roaksoax> rock: was maas able to power on the machines ?
<jwitko> ty
<jwitko> that is a real bummer.  is that publicized anywhere on the docs?
<rock> roaksoax: Yes.
<rock> baldpope: OH. I got the same juju bootstrap error. I rerun the Openstack installer. Third time I got succeded.
<rock> roaksoax: When we start commissioning MAAS able to power on the machines.
<jwitko> roaksoax, can you run maas 1.9 on ubuntu 16.04 ?
<roaksoax> jwitko: no, only 2.0
<roaksoax> jwitko: 1.9 doesn't support python3
<roaksoax> 2.0 doesn't support python2
<kiko> roaksoax, isn't there an independent client library they could use that does support python2?
<kiko> or is the issue that any library will not have been updated for MAAS2?
<roaksoax> kiko: the 1.9 client library won't work with 2.0. Working with the 2.0 API requires python3
<jkov> What is the best way to install the debs that result from package-dev make target?
<kiko> roaksoax, well, working with the 2.0 API could be implemented in brainfuck or bash tbh :-) it's more that the API we ship is python3 :-)
<kiko> I mean it IS just REST :-)
<mup> Bug #1519828 changed: [2.1] Support for static routes <canonical-bootstack> <MAAS:Fix Released> <MAAS 1.9:Won't Fix> <MAAS 2.0:Won't Fix> <https://launchpad.net/bugs/1519828>
<mup> Bug #1519828 opened: [2.1] Support for static routes <canonical-bootstack> <MAAS:Fix Released> <MAAS 1.9:Won't Fix> <MAAS 2.0:Won't Fix> <https://launchpad.net/bugs/1519828>
<baldpope> rock, kiko is it possible the juju error is because the image pushed (during commissioning) has a key already defined?  not sure what to look for in some of these errors
<mup> Bug #1519828 changed: [2.1] Support for static routes <canonical-bootstack> <MAAS:Fix Released> <MAAS 1.9:Won't Fix> <MAAS 2.0:Won't Fix> <https://launchpad.net/bugs/1519828>
<mup> Bug #1623598 opened: [2.1, vanilla] Settings page do not have separators for the config sections <MAAS:New> <https://launchpad.net/bugs/1623598>
<mup> Bug #1623599 opened: [2.1, vanilla] Settings page do not have separators for the config sections <ui> <ux> <vanilla> <MAAS:New> <https://launchpad.net/bugs/1623599>
<Kiall> Hey, so - I'm trying to create some custom images - debian based, LVM backed, but anything I upload fails to deploy.. Anyone know of some docs for handling custom images? (Beyond what's in the maas docs themselves), or open source tools I can check the code in for building the images?
<kiko> Kiall, there are no docs beyond the MAAS docs, and we are spread really thin post-2.0
<kiko> Kiall, if you're interested we'd be happy to sell you a professional services engagement to help you build an image customization pipeline
<kiko> but we're being a bit victims of our own success right now :)
<Kiall> Hah, always with the upsell ;)
<Kiall> I'll keep digging, thanks :)
<kiko> Kiall, think of all the hungry programmers
 * Kiall works on OpenSource for a living too, and is also quite hungy ;)
<baldpope> Kiall, where you at? can I buy you a donut?
<Kiall> lol - Ireland ;)
<baldpope> suprised there's not a ${cryptocoinoftheday} bot running - allow people to tip each othere here
<baldpope> Kiall, buy you a stout?
<Kiall> Maybe next time ;)
<mup> Bug #1623634 opened: [2.1] Trying to cancel an image import from the new Images page results on it not being cancelled on the backend. <angular-images> <MAAS:Confirmed> <https://launchpad.net/bugs/1623634>
#maas 2016-09-15
<mup> Bug #1623751 opened: [2.1] MAAS takes a long time to save settings <MAAS:Confirmed> <MAAS 2.0:New> <MAAS trunk:Confirmed> <https://launchpad.net/bugs/1623751>
<mup> Bug #1623752 opened: [2.1] Settings page still lists 'Boot Images' section <MAAS:New> <https://launchpad.net/bugs/1623752>
<mup> Bug #1623753 opened: [2.1] New images page doesn't have option to enable/disable automatic image sync <MAAS:New> <https://launchpad.net/bugs/1623753>
<mup> Bug #1623760 opened: [2.1] If Region and Rack controller are in the same machine, NTP service tracker is listed under rack <MAAS:Triaged> <https://launchpad.net/bugs/1623760>
<nirlevy> Hi All, MAAS for auto pilot, do the MAAS node itself is part of the 5 nodes? does it's node should be commissioned in it's dashboard?
<HeinMueck> Hi guys!
<HeinMueck> Sorry to interrupt :)
<HeinMueck> Just posted this on answers ... http://askubuntu.com/questions/825095/does-maas-have-an-event-queue-that-i-can-listen-to
<HeinMueck> oh
<HeinMueck> its ask :))
<nirlevy> Is the MAAS node itself sould be listed and commissioned?
<mup> Bug #1623851 opened: Tables not responsive for mobile <ui> <MAAS:New> <https://launchpad.net/bugs/1623851>
<mup> Bug #1623852 opened: The page header is not responsive for small screen width and mobile screens <MAAS:New> <https://launchpad.net/bugs/1623852>
<mup> Bug #1623851 changed: Tables not responsive for mobile <ui> <MAAS:New> <https://launchpad.net/bugs/1623851>
<mup> Bug #1623852 changed: The page header is not responsive for small screen width and mobile screens <MAAS:New> <https://launchpad.net/bugs/1623852>
<mup> Bug #1623851 opened: Tables not responsive for mobile <ui> <MAAS:New> <https://launchpad.net/bugs/1623851>
<mup> Bug #1623852 opened: The page header is not responsive for small screen width and mobile screens <MAAS:New> <https://launchpad.net/bugs/1623852>
<mup> Bug #1623878 opened: mDNS label contains disallowed characters <MAAS:Triaged> <https://launchpad.net/bugs/1623878>
<rock> roaksoax: Hi. Now we only have the issue is : MAAS not able to detect  node disks. MAAS changing nodes state from commissioning to Ready. Nodes power state is "ON".  https://imagebin.ca/v/2v9uPsoTQ6Pi
<rock> roaksoax: Could you please provide me some solution for this.
<roaksoax> rock: the machine after commissioning will be market ready
<roaksoax> rock: and you need to wait for maas to update the power
<roaksoax> rock: if there are no disks discovered
<roaksoax> rock: change the disks to IDE or VirtIO or something similar
<roaksoax> rock: and re-commission
<nirlevy> Hi All, MAAS for auto pilot, do the MAAS node itself is part of the 5 nodes? does it's node should be commissioned in it's dashboard?
<mup> Bug #1621901 opened: lacks support for ipv6 addresses <maas-ipv6> <MAAS:New> <ipmitool (Ubuntu):New> <ipmitool (Debian):Confirmed> <https://launchpad.net/bugs/1621901>
<rock> roaksoax: Hi. I tried with IDE. It is not worked. I will try with VirtIO  and Other. Thank you.
<rock> nirlevy: Hi. MAAS node is itself is part of the 5 nodes.
<rock> nirlevy: If you take 5 nodes, One node is for MAAS, One is for Landscape and remaining three nodes are for Openstack deployment through Autopilot.
<rock> nirlevy: you need to commission 4 nodes except MAAS node.
<nirlevy> Thank you rock, so I will remove it from it's state "new" in the nodes.
<FredFoo> Does Maas have an event system? http://askubuntu.com/questions/825095/does-maas-have-an-event-queue-that-i-can-listen-to
<FredFoo> Some interface I can connect to and get a notification when the commissioning or deployment is finished for a machine?
<neith> anyone knows where to find any help whit openstack-install in single mode?
<roaksoax> rock: fwiw, my VM's are configured with VirtIO
<rock> roaksoax: Thank you . I am trying with 'VirtIO'. Commissioning in Progress
<evidex> Is there a mechanism to pass a script to maas to be run on the first boot of a node? Something similar to AWS's user_data scripts?
<evidex> All I can seem to find are "Comissioning Scripts", which don't seem appropriate.
<roaksoax> evidex: user_data
<roaksoax> evidex: check the API on 'start or deploy'
<HeOS> Hello! I've tired to install maas from stable repo - I can connect to the mass' UI, but I see there is no configured controller. I see the following error in the rackd.log: http://paste.openstack.org/show/577464/. How can I configure a controller there?
<mup> Bug #1623994 opened: [2.1]  When trying to enable DHCP - Name or service not known <MAAS:Confirmed> <https://launchpad.net/bugs/1623994>
<rock> roaksoax: Hi.  For one node I given VirtIO disks, for second node I gave SCSI disks.  Then MAAS detected hard disks. And also I tried with "VirtIO SCSI disk", "IDE" and "SATA" and "USB". These disk types not detected by MAAS.
<rock> roaksoax: we first added Chasis and then started commissioning of all nodes. All nodes are not commissioning successfully ata a time. Some nodes are failing with Error: node marking failed , operation commission failed after time out 0:20:00.
<rock> roaksaox: When we try to recommission the failed nodes again and again then they commissioning successfully.
<rock> roaksoax: Do you face the same issue while commissioning nodes in your setup.
<rock> roaksoax: In maas.log file, I saw the following error repeatedly. ISSUE :   maas-server maas.lease_upload_service: [ERROR] Failed to upload leases: 'str' object has no attribute 'mac'
<rock> roaksoax: Why we are getting this error repeatedly. Do you have any idea? Is this error will effect the commissioning process?
<rock> roaksoax: maas.log : http://paste.openstack.org/show/577660/
<mup> Bug #1624035 opened: [2.1] Missing support for icons inside input fields <ui> <vanilla> <MAAS:Triaged> <https://launchpad.net/bugs/1624035>
<okinWhitePlains> my first time here, so please excuse
<okinWhitePlains> having trouble enlisting nodes to maas
<brendand> okinWhitePlains, what kind of nodes?
<brendand> and which version of maas?
<okinWhitePlains> MAAS Version 1.9.4+bzr4592-0ubuntu1 (trusty1)
<okinWhitePlains> I have 5 Dell R610 for the nodes
<brendand> ah ok. whats the issue? do they pxe boot?
<okinWhitePlains> yes, they get an IP and boot then get stuck at meta data source
<okinWhitePlains> the boot completes but the node stays powered up and does not appear in maas
<brendand> okinWhitePlains, any chance you can provide the last lines(s) shown on the nodes?
<okinWhitePlains> at the point it gets stuck I see the following: url-helper.py Calling http://169.254.169.254/2009-04-04/meta-data/instance-id failed [150/120s]
<okinWhitePlains> request error .. urllib3.connectionpool.HTTPConnectionPool object ... connection timed out
<johncrist> o/ Good morning/afternoon/evening all
<okinWhitePlains> hello
<brendand> okinWhitePlains, it's likely the node can't talk to the controller then
<johncrist> How do you guys prefer a question be asked? Just thrown out there? Wait for someone to open up?
<johncrist> I don't want to inconvenience or cut in on anyone
<okinWhitePlains> it's able to get the image to boot. What config should I look at?
<brendand> johncrist, throw it out there
<johncrist> So I've set up a little test bed in my office: http://i.imgur.com/DGmWkDA.jpg
<johncrist> Per the documentation I've 5 systems with 2 hard drives, two of which have two nics: http://i.imgur.com/AtYv7D7.jpg
<johncrist> The top server is my region controller and the second is my rack controller
<johncrist> I have a line feeding into the top switch (orange) that's my live 'internet' connection. The blue switch I have the region and rack controller plugged into. The second nic on the region controller isn't doing anything (the docs didn't specify so far as I saw). The rack controller is also plugged into the blue switch and I can see the rack controller in the web interface: http://i.imgur.com/Aesk3sK.jpg
<johncrist> The lower switch is plugged into the second nic on the rack controller and currently has one node plugged into it as well.
<johncrist> In my mind I feel like the second nic on the rack controller should have a switch with the rack controllers plugged into it, and then each rack controller having it's own switch for the nodes, but I may be wrong about that. In either case that's how I'm currently set up.
<johncrist> What I'm seeing is that the second interface on the rack controller is unconfigured, and I'm unsure of how to 'configure' it in the web interface
<brendand> okinWhitePlains, you're sure the http port is open on the server?
<johncrist> I've assigned it a fabric, set a subnet on the fabric, and enabled DHCP
<okinWhitePlains> I'm sure it's open. I can retrieve packages and install updates
<johncrist> http://i.imgur.com/i91TVYl.png
<johncrist> Did we break him?
<johncrist> o/ userland
<nturner> I'm seeing an interesting error adding a 2nd rack controller: https://paste.ubuntu.com/23183345/
<userland> hello I see on maas website that there is possible to use ansi ble with maas
<userland> where can I read some docs about it? It's tricky to find :)
<johncrist> That's an excellent question. I'm here for help, too, so I'm not sure I have an answer for you :P
<userland> lol i hope you are joking :P
<userland> and you have an a great answer 8)
<okinWhitePlains> Can anyone check if http://169.254.169.154 is up or I'm being blocked from getting to it
<okinWhitePlains> It the datasource site for metadata
<userland> 169.254.169.254 is run localy on your env its not routable
<johncrist> Was gonna say
<johncrist> Hey userland -- ever run into a situation where a rack has an interface that you just can't configure?
<johncrist> Like you set up the subnet and vlan and enable DHCP, but the interface just remains unconfigured?
<userland> well I'm using maas from yesterday but I've runned it standalone and in lxc. Everytime you need to make proper interface configuration before you will start working with rack
<userland> mass everytime discovered my interfaces properly but they should be ok after ifup them
<johncrist> I'm wondering if MaaS discovers things upon install only
<userland> perhaph rack restart will help - you lose nothing
<okinWhitePlains> how do I check if 169.254.169.254 is running?
<userland> just try telnet it on port 80
<userland> curl will also work
<johncrist> That address is a local only net though
<johncrist> You only see it when nothing gets assigned
<userland> if not then restart your metadata server or check network connectivity. On Openstack you neet to have a router and gateway from your network. Other wise you will not be able to connect to metadataserver
<okinWhitePlains> I only have maas up. Openstack will come later, if I survive. So in maas, where to find the config for the metadataserver
<userland> you do not need it
<userland> tell what you are  trying to do ATM
<okinWhitePlains> my nodes and not enlisting in maas
<userland> and you see errors about 169.254.169.254 on your nodes console?
 * nturner realized the new rack controller was running 2.0 and the region controller running 2.1 alpha
<nturner> after updating so they match, I see https://paste.ubuntu.com/23183485/
<okinWhitePlains> that's right
<okinWhitePlains> url-helper.py Calling http://169.254.169.254/2009-04-04/meta-data/instance-id failed [150/120s]
<okinWhitePlains> request error .. urllib3.connectionpool.HTTPConnectionPool object ... connection timed out
<HeOS> Folks, excuse me, can someone help me with my problem, what I've described earlier?
<mup> Bug #1623266 changed: [web UI] Proxy is for APT only <docteam> <MAAS:Invalid> <https://launchpad.net/bugs/1623266>
<userland> someone was asking about new interfaces
<userland> I added to my maas VM new interface
<userland> resterted the maas and it see my new virtual interface with its network
<userland> guess I was right
<HeOS> userland, I wrote about a problem with controller.
<HeOS> userland, I can't connect it to my maas instance and the following errors in logs: http://paste.openstack.org/show/577464/.
<userland> I don't know if maas is using rpc
<userland> but usually no rpc endpoint is because portmap is not working
<userland> dunno if it will help
<HeOS> userland, it worked yesterday on the same OS on another VM.
<HeOS> I tried to install it on a baremetal server today, but it doesn't work.
<HeOS> I can't figure out why it's happened.
<userland> the same error?
<HeOS> userland, yes.
<HeOS> I've tired to install it on KVM's VM and bare metal today. It doesn't work.
<userland> im trying to run 2.0 via 16.04 on bare metal atm
<HeOS> But it works on the VM, what created in virtualbox.
<userland> tftp doesn't work
<userland> my tftp started to work. removed all boot images re-imported them
<userland> I was asking for support to ansible but no one helped me too. Do you have full log for your BM?
<userland> what was haooening before this error showd
<HeOS> userland, maas writes in the log, that it starts some servers on 69 port.
<HeOS> userland, I'll try install it in VirtualBox again.
<userland> 69 is tftp port
<HeOS> userland, yup, I know.
<mup> Bug #1624118 opened: Primary DNS entry for a node ends up using wrong address <MAAS:Incomplete> <https://launchpad.net/bugs/1624118>
<FredFoo> Good day all! Anyone has a comment on this question? http://askubuntu.com/questions/825095/does-maas-have-an-event-queue-that-i-can-listen-to
<mup> Bug #1624154 opened: Rack unable to import files from region <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1624154>
#maas 2016-09-16
<mup> Bug #1578059 changed: Default route not coming up with juju 1.25.5 and bonding <canonical-bootstack> <juju-core:Expired> <MAAS:Expired> <MAAS 1.9:Expired> <https://launchpad.net/bugs/1578059>
<mup> Bug #1620838 changed: [2.1a2] Got more than one neighbor <MAAS:Won't Fix by mpontillo> <https://launchpad.net/bugs/1620838>
<mup> Bug #1620838 opened: [2.1a2] Got more than one neighbor <MAAS:Won't Fix by mpontillo> <https://launchpad.net/bugs/1620838>
<mup> Bug #1620838 changed: [2.1a2] Got more than one neighbor <MAAS:Won't Fix by mpontillo> <https://launchpad.net/bugs/1620838>
<mup> Bug #1624344 opened: [2.1] Can't SSH to machine in Rescue mode <MAAS:New> <https://launchpad.net/bugs/1624344>
<mup> Bug #1518414 changed: [1.9] Trusty commissioning (hwe-t) - NVMe model info/serial number is not seen <canonical-bootstack> <MAAS:Invalid> <https://launchpad.net/bugs/1518414>
<rock_> roaksoax: Hi. Yesterday MAAS detected one ISCSI node and one VirtIO node. But remaining VirtIO nodes MAAS not detecting https://imagebin.ca/v/2vHCKR5GkVrx.
<rock_> roaksoax: I retry the commission again and again. But it was not able to detect disks
<roaksoax> rock_: that seems like a bug then
<roaksoax> rock_: please file a bug
<rock_> roaksoax: I deleted all nodes. Again I created 4 nodes with VirtIO disk type. This type MAAS not able to detect disks even for a single nodes also. I recomissioned 5 times. But no use. For ISCSI disk type also the same problem. https://imagebin.ca/v/2vHE0iUlhP07
<rock_> roaksoax: you think , This might be KVM host problem?
<mup> Bug #1624380 opened: [2.1] When passing parameters to maas createadmin, it prompts for ssh-import <MAAS:New> <https://launchpad.net/bugs/1624380>
<rock_> roaksoax: For your setup which company server you have taken? and what was the configuration of that server?  Can you please tell me?
<roaksoax> rock_: i don't have a production environemnt
<roaksoax> rock_: i have testing environments
<roaksoax> multiple of them
<roaksoax> rock_: I test 1. kvm's (on a xenial host, VM';s with VirtIO). 2. NUC's 3. servers (a wide variety), IPMI based
<rock_> roaksoax: Now  I am using KVM VMs on trusty host. This may be an issue?
<roaksoax> rock_: you are using MAAS 1.9 right ? that may be a bug in MAAS
<rock_> roaksoax: YES. May be. MAAS 2.0 supports trusty?
<rock_> roaksoax: If it supports, For installing MAAS 2.0 packages on trusty what was the best Doc?
<roaksoax> rock_: you cannot install 2.0 in trusty, only xenial+ but 2.0 supports deploying all OS versions
<roaksoax> rock_: and this is likely to be a bug in 1.9
<mup> Bug #1624403 opened: [2.1] Machines go back to Deployed from Rescue mode, before they actually are <MAAS:New> <https://launchpad.net/bugs/1624403>
<rock_> roaksoax: Can I try like this. By taking KVM host OS as trusty, In one of KVM VM I install Xenial and on top of that I will install MAAS 2.0.
<mup> Bug #1624403 changed: [2.1] Machines go back to Deployed from Rescue mode, before they actually are <MAAS:New> <https://launchpad.net/bugs/1624403>
<mup> Bug #1624403 opened: [2.1] Machines go back to Deployed from Rescue mode, before they actually are <MAAS:New> <https://launchpad.net/bugs/1624403>
<mup> Bug #1624424 opened: MAAS not able to detect disks of KVM virtual machines <MAAS:New> <https://launchpad.net/bugs/1624424>
<baldpope> greetings all
<baldpope> gonna try to deploy openstack via maas
<baldpope> OK, ran into this problem on each of 5 hosts I try to deploy
<baldpope> each return the cpu count/ram/storage
<baldpope> and watching the console, each report back with the node name at the login prompt (blade 1 through 5)
<baldpope> but all report 'failed commissioning' in the web ui
<baldpope> is there a log some place that I can review the failed installation?
<baldpope> i have login access to each of the 5 nodes, the local disks are blank, root is mounted via iscsi
<baldpope> but where are logs stored for the commission step?
<brendand>  /var/log/maas/rsyslog
<baldpope> brendand, on the maas server, i assume?
<brendand> baldpope, yes
<baldpope> Sep 16 10:54:02 brk-maas-1 maas.import-images: [WARNING] I/O error while syncing boot images.
<baldpope> i see that in maas.log
<baldpope> but the nodes/blades are all up, so not sure if the error is valid?
<baldpope> would it be worth it to delete and reimport the images?
<baldpope> rather, sync ?
<kiko> baldpope, that means that the images aren't being synced, and I think it's to the region
<kiko> baldpope, do you have a proxy?
<baldpope> kiko, short answer yes
<kiko> baldpope, long answer, a complicated one?
<baldpope> longer answer is that I assume there are two proxies, the internal one specific to maas and then my own?
<kiko> correct
<kiko> the maas proxy is only used for package installation on the nodes
<baldpope> ok, then yea
<kiko> and only if you haven't specified an external proxy
<kiko> if you have specified an external proxy, that's what we tell the nodes to use
<baldpope> 1sec - let me check network in maas
<baldpope> ok, i did define the proxy in settings, let me remove that as I don't think I gave network access between the two segments
<kiko> okay
<kiko> and next, your external proxy may be messing with the large image download
<baldpope> cool - i'll check 1sec
<baldpope> i think removing the internal proxy fixed it, updating my notes..
<baldpope> thanks kiko
<baldpope> watching the consoles - it hasn't failed yet -and still shows commissioning in the webui
<baldpope> would have said failed by now
<baldpope> yea - blade3 just flipped to ready
<baldpope> so question - ready doesn't necessarily mean that an OS has been deployed right, if I were to boot, would I see an image on the local disks?
<baldpope> or is the OS (per blade) always stored on the maas head?
<baldpope> and (unrelated) ... why can't I paste in the ubuntu session when I run the openstack installer - i keep having to manually type the api key
<baldpope> frustrating to say the least...
<baldpope> ok, proceeding - bootstrapping juju
<baldpope> hm
<baldpope> maas is showing deployed (from deploying) but openstack-installer is still sitting at the bootstrapping juju screen
<kiko> baldpope, they are blank still
<kiko> baldpope, I know you will find this weird
<baldpope> so far.. i don't find anything weird
<baldpope> other than the openstack-install not finishing
<baldpope> blade1 is up (post deploy) but openstack-install is just sitting here
<baldpope> from the doc, it should complete and provide a url to start managing landscape
<baldpope> the only listening port on that is tcp port 22
<baldpope> and I can login with the ubuntu user and the public key that was added
<kiko> baldpope, but I would not use openstack-install :)
 * baldpope sigh
<kiko> baldpope, instead, deploy openstack directly with a bundle
<baldpope> so... this article - http://maas.io/get-started
<baldpope> i should just ignore?
<kiko> no no
<kiko> you did the hard part, which is getting maas set up
<kiko> can maas deploy Ubuntu to all the nodes?
<kiko> successfully? you can SSH into them, etc?
<kiko> that's the last piece of the proof point
<kiko> https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/
<baldpope> yea - maas so far (getting the blade up and running with no local installation) is gtg
<baldpope> sorry, i was meant this article -http://www.ubuntu.com/download/cloud
<baldpope> reading your link now
<kiko> baldpope, are you on 1.9 or 2.0?
<coreycb> anyone knowledgable on maas deployments with lxd?  trying to figure out why containers on one machine can't access containers on another.
<baldpope> l$ juju --version
<baldpope> 1.25.6-trusty-amd64
<baldpope> MAAS Version 1.9.4+bzr4592-0ubuntu1 (trusty1)
<kiko> coreycb, yep
<kiko> coreycb, what did you do in lxd init?
<kiko> baldpope, okay, yeah 1.9
<coreycb> kiko, nothing :)
<kiko> baldpope, let's do a bundle deploy
<kiko> coreycb, heh, okay, lxd init first and choose your networking mode
<baldpope> kiko, ok - been at this most of the morning - gonna take a quick break for lunch- bb soon
<kiko> baldpope, sorry, I have asked that we deprecate openstack-install from the website, because the experience is often sad
<coreycb> kiko, ok but this is a deploy to maas machines and then containerizing some of the services, so I can't lxd init until after the fact
<kiko> coreycb, how is the containerizing being done? by hand?
<coreycb> kiko, no i'm using the openstack bundle from the charm store
<kiko> coreycb, gotcha. and juju 2 or 1.25?
<coreycb> kiko, juju 2
<kiko> coreycb, can you correctly deploy Ubuntu to the nodes using MAAS alone, and networking between them works?
<coreycb> kiko, I'd have to check but I'd guess not.  they're running on lxdbr0 so I'm wondering if juju should be setting up a different bridge.
<kiko> coreycb, so here's the thing: if MAAS can deploy a node with working networking, then any container setup is either the bundle being wrong or a bug in Juju
<kiko> coreycb, beta14?
<coreycb> kiko, ok I'll ask around and see if it's a known issue with juju. it's beta15.
<PCdude> When I install 1.9.4+bzr4592-0ubuntu1~trusty1 ( of MAAS) it fails. Eearly this week I find out (accidentally ) that 1.9.4+bzr4592-0ubuntu1~14.04.1 ( MAAS) does work. I wanted to force the latter version, but I get unmet dependencies error. How can I solve this?
<PCdude> This is what I tried: http://askubuntu.com/questions/148638/how-do-i-enable-the-universe-repository#227788
<PCdude> This is the error I get: http://askubuntu.com/questions/818368/maas-1-9-4-install-fails-on-ubuntu-14-04-caused-by-a-database-failure
<PCdude> kiko: maybe u have an idea?
<roaksoax> coreycb: Juju creates bridge interfaces after MAAS has made the deployment, if juju fails creating those interfaces, your machine will be shown as 'deployed' but everything else will be borked
<roaksoax> PCdude: you are not attaching a pastebin on how it is failing :)
<roaksoax> PCdude: one would be ideal to see what's wrong
<kiko> roaksoax, did you see the picture?
<kiko> PCdude, if you apt-get install postgresql-server before installing maas-region-controller does it work?
<roaksoax> PCdude: that seems like your postgresql is:
<roaksoax> 1. not running
<roaksoax> 2. not accepting connections in localhost
<PCdude> This is what I got when I tried to install postrgresql-server: http://pastebin.com/raw/cK2dLTCr
<roaksoax> PCdude: sudo apt-get install postgresql
<PCdude> install postgresql, its is now installing maas again. lets see if it succeeds
<PCdude> same error
<roaksoax> PCdude: what's it /etc/maas/regiond.conf ?
<roaksoax> PCdude: and what does: sudo service postgresql status tell yo u?
<PCdude> the first one has exactly one line "maas_url: http://[ip]/MAAS"
<PCdude> the second one has no output
<PCdude> just gives me the next line to put my command on
<roaksoax> PCdude: for the message in the image, either postgresq not running or not accepting connections
<roaksoax> PCdude: what does the pg_hba.conf config has ?
<roaksoax> PCdude: make sure postgresql is up and running
<kiko> PCdude, I think you can figure out how to get postgresql up and running -- come back to us later when you have figured it out :-)
<PCdude> yeah, I was trying some other things that could help :) but let me do that first
<PCdude> kiko: roaksoax ok problem solved. BY default version 9.3 is installed. I added the PPA of postgresql and I could update to an higher version. With that version MAAS is now able to install :)
<kiko> PCdude, MAAS works with 9.3 though
<roaksoax> PCdude: i think your custom progress doesn't allow connections or doesn't run correctly
<PCdude> kiko: well not here apparently :)
<kiko> PCdude, you are doing something weird
<PCdude> well all I did was installing ubuntu 14.04 and setup the network after that I installed maas. thats it
<kiko> version 9.3 was not running when you tried to install the region controller
<PCdude> kiko: but that is something that MAAS is responsible for right? I mean, the MAAS installer should install postgresql itself
<kiko> PCdude, if you apt-get install maas, you get it installed
<kiko> and if you apt-get install maas-region-controller, you get it too
<kiko> Package: maas-region-controller
<kiko> Depends: maas-region-controller-min (= 1.5+bzr2252-0ubuntu1), postgresql (>= 9.1), rabbitmq-server, debconf (>= 0.5) | debconf-2.0
<kiko> trust me :)
<PCdude> kiko: I trust you, but apparanetly something went wrong there. I did not installed postgresql before that or had any weird configuration files
<PCdude> but something triggered it
<kiko> PCdude, something is wrong with your system
<PCdude> kiko: like what?
<baldpope> kiko, back
<kiko> PCdude, no idea. but apt-get install maas-region-controller does set postgresql up for you, automatically
<PCdude> kiko: and u are sure that maas version 1.9.4 should work with 9.3 of postgresql?
<kiko> PCdude, yes, 10000% sure
<PCdude> kiko: I believe u :) , I have no idea what could have gone wrong. Seriously, its all fresh and no weird things
<roaksoax> PCdude: so you filed this right? https://bugs.launchpad.net/maas/+bug/1618847 ?
<roaksoax> I can close it
<roaksoax> \o/
<PCdude> roaksoax: yup, good point. that one can be closed
<mup> Bug #1618847 changed: MAAS install fails, problem with database <MAAS:Invalid> <https://launchpad.net/bugs/1618847>
<mup> Bug #1618847 opened: MAAS install fails, problem with database <MAAS:Invalid> <https://launchpad.net/bugs/1618847>
<mup> Bug #1618847 changed: MAAS install fails, problem with database <MAAS:Invalid> <https://launchpad.net/bugs/1618847>
<PCdude> uhm mup why are u posting the same error 3 times? :)
<baldpope> he was filing in triplicate
<baldpope> kiko, back to that article re: openstack deployment with juju
<kiko> baldpope, let's see
<baldpope> can maas act as a gateway to the intenral cloud, or does the nodes need network access without maas?
<kiko> it can act as a gateway, just specify it as the gateway
<kiko> and NAT as necessary
<baldpope> k
<kiko> baldpope, and coreycb seems to be following the same instructions
<baldpope> could be
<baldpope> kiko, interestingly enough, I found this article while prepping - seems to be a slightly newer version by same author
<kiko> baldpope, ah
<baldpope> grumble. paste not working in hexchat...
<baldpope> insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/
<kiko> ah, yes
<kiko> this is dimitern's good work
 * baldpope sigh
<baldpope> kiko, so ... http://pastebin.ubuntu.com/23188223/
<kiko> baldpope, what's the single quotes
<baldpope> just that - nothing in them
<baldpope> following the url I posted earlier
<baldpope> ohg
<baldpope> i'm retarded...
<baldpope> nope nevermind..
<baldpope> same error
<kiko> baldpope, remove the single quotes
<baldpope> yea - i'm not that bright - i see what I did wrong
<baldpope> remove single quotes and give it a name before the URI
<kiko> yep
<baldpope> it's been a long week
<kiko> baldpope, well, the docs are wrong, right?
<baldpope> meh - i'm not going to blame the docs
<baldpope> there are inconsistencies
<baldpope> i mean step 9 has it written one way, then in his notes immediately below, he has it written an alternate way
<baldpope> not sure if it's been discussed before, but if it could be noted in the maas client or in documentation that the api key input is masked
<baldpope> so someone copy/pasting the api key knows that they won't see it pasted
<mup> Bug #1624516 opened: [2.1, FUJ] When removing the ports archive, a weird error message was shown <MAAS:Confirmed> <https://launchpad.net/bugs/1624516>
<baldpope> the vlan interfaces need to be configured prior to being configured in maas?
<mup> Bug #1624516 changed: [2.1, FUJ] When removing the ports archive, a weird error message was shown <MAAS:Confirmed> <https://launchpad.net/bugs/1624516>
<kiko> baldpope, well.. prior to the node being deployed, yes
<baldpope> kiko, and prior to configuring it maas (which admittedly makes sense, but documentation isn't explicit)
<baldpope> probably just being picky
<baldpope> i only make not of it because if you don't do it before installing maas, then it doesn't show up in subnets (the fabrics)
<mup> Bug #1624516 opened: [2.1, FUJ] When removing the ports archive, a weird error message was shown <MAAS:Confirmed> <https://launchpad.net/bugs/1624516>
<mup> Bug #1624522 opened: [2.1, UI, UX] Weird location to put the "Automatically sync images" toggle button <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1624522>
<coreycb> kiko, fyi I think this is what I'm hitting: https://lists.ubuntu.com/archives/juju/2016-September/007801.html
<kiko> coreycb, ah, yes, on 2.0 there is that snag
#maas 2016-09-17
<PCdude> kiko: I ran into a problem again :)
<PCdude> kiko: that is the error log of the bootstrapped machine: http://pastebin.com/raw/TtwnS1CM
<PCdude> it gives an error code 1 when there is no KVM support is that necessary?
<eject_ck> Hi all
<eject_ck> trying to bootstrap juju 2 with maas 2 in 16.04 getting juju bootsrap hung when "Fetching" gui. I've added âdebug and log. Please advice why hangs ? https://0bin.link/paste/hehQjxRA#sv0PImHpJHuOv1-FA3yUmgMpN2ycDe+1CS3HEg5oNl8
<mup> Bug #1624693 opened: [2.1] Rack failed to run/register on fresh install <MAAS:New> <https://launchpad.net/bugs/1624693>
<Guest17230> Greetings. I am just getting started (~30 minutes ago) with MAAS, and I don't understand the documentation.
<Guest17230> I did an install from the Ubuntu Server ISO and it configured my region and rack controller
<Guest17230> Now I am here: http://maas.io/docs/installconfig-dhcp
<Guest17230> The first thing is that my version is "MAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1)" and it doesn't quite line up with what the documentation says (things are just a little off). I am guessing it is just an update to the software and the docs are still catching up.
<Guest17230> So I go to my "Networks" tab and I don't have a VLAN option....
<Guest17230> but I can add one, so I do.
<Guest17230> It shows my fabric-2 with two VLANs now. An "Untagged" and the one that I just created.
<Guest17230> Well, that doesn't seem to be what the documentation says...So I delete the one I just created, and go to the "untagged"
<Guest17230> But I can't add a subnet to "Untagged" like the documentation says to do!
<Guest17230> It just isn't an option.
<Guest17230> If I try to just add "Provide DHCP" I get the error "No subnets are available on this VLAN. DHCP cannot be enabled."
<Guest17230> command line doesn't work either....
<Guest17230> {"primary_rack": ["Select a valid choice. UbuntuMaas.maas is not one of the available choices."], "dhcp_on": ["dhcp can only be turned on when a dynamic IP range is defined."]}
<Guest17230> Hrmm...something isn't configured right with the dhcp...
<Guest17230> BTW, to whoever made the decision to use JSON instead of YAML...I just want to let you know that I love you...
<Guest17230> JSON is just so easy to work with and I hate YAML so very much...as I am evaluating several different things to provision out server builds it seems a lot of them use YAML and it irritates me to no end....
<Guest17230> Anyway...back to the dhcp problem...
<Guest17230> Hrm. It looks like it isn't properly configuring my network cards....I will do that manually...
<Guest17230> Hrm. Well...that "works"
<Guest17230> After I manually assigned a network/ip to the network card, then I somehow managed to create a subnet that it liked (it didn't like most of what I tried to give it) and it finally created a dhcp pool...
<Guest17230> Although my add network dhcp page looks /nothing/ like the documentation page...
#maas 2016-09-18
<rock__> roaksoax: Hi. MAAS on KVM machines.  I installed MAAS 2.0 on Xenial [KVM virtual machine]. And I have created 4 KVM VMs to act as MAAS nodes by enabling PXE boot while creating. I added Chassis from MAAS UI. Started commissioning of all nodes.
<rock__> roaksoax: MAAS not able to commission its nodes. Giving ERROR: node marking failed : Operation commission failed after 0:20:00.
<rock__> roaksoax: For commissioning i tried with both Xenial and trusty image[From MAAS UI]. But no use.
<rock__> roaksoax: Please provide me some solution for this.
<rock__> roaksoax: maas log and rackd log info  http://paste.openstack.org/show/580716/
<nirlevy> [ERROR: 09-18 08:42:38, ev.py:130] Exception in ev.run(): Traceback (most recent call last):   File "/usr/share/openstack/cloudinstall/ev.py", line 128, in run     self.loop.run()
<nirlevy> installing openstack auto pilot I am getting the following, any clues,Thanks.
<samba35> i am new to maas ,i am on 16.04.1 ,i am getting web gui now how do i add machine to inventory  ?
<pragsmike> rock__: try this: In Settings uncheck "Enable the use of an APT and HTTP/HTTPS proxy"
<pragsmike> and for "Enable DNSSEC validation of upstream zones" set it to No
<samba35> can some one please tell me from where do i start ,getting started guide ?
<rock__> pragsmike: Thank you. I will try this.
<nirlevy> any one knows what is the reason DNS failed on my MAAS? it is installed with maas-dns.
<samba35> Sep 18 21:31:50 ubuntu16 sh[2542]: 2016-09-18 21:31:50 [-] 127.0.0.1 - - [18/Sep/2016:16:01:49 +0000] "GET /MAAS/rpc/ HTTP/1.0" 200 416 "-" "provisioningserver.rpc.clusterservice.ClusterClientService" what is meaning of this error
<rock__> pragsmike: Hi. I did as you said. But I am facing the same issue. Please tell me what I need to do.
<PCdude> hi all :)
<PCdude> is it possible to make a HA setup with MAAS 1.9.4?
<PCdude> I see some docs for 2.0+ ,but not for 1.9.x
<PCdude> kiko: u have an idea on HA for MAAS 1.9.x?
<marc__> hi all - i'm needing help with maas 2.0  - the pxe boots always report file not found. the ip is correct for the maas server but does not find the file it needs
<marc__> ha it was a firewall rule, interesting... pfsense...
#maas 2017-09-11
<mup> Bug #1704028 changed: [2.3, HA] Registering a second region api causes strange traceback <MAAS:Expired> <https://launchpad.net/bugs/1704028>
<deepu> hi please guide for installtion of MAAS to confogure openstack
<mup> Bug #1716328 opened: [2.2] VM creation with pod accepts the same hostname and push out the original VM <MAAS:New> <https://launchpad.net/bugs/1716328>
<Guest72371> Hi, wanted to check if someone has working on custom maas repo management. I have configured custom maas repo, and how wanted to import custom kernel into simplestreams repo for MAAS, but not sure of how it needs to be imported. If someone has already worked and can provide some inputs that would be great.
<Guest72371> basically, main issue is how to sign the image file that needs to be uploaded to the repo? Do we need to define any metadata structure?
<mup> Bug #1716492 opened: maas-dns floods syslog by reloading all zones every 2 seconds <amd64> <apport-bug> <xenial> <maas (Ubuntu):New> <https://launchpad.net/bugs/1716492>
<mup> Bug #1716493 opened: Machine ownership visibility option <MAAS:New> <https://launchpad.net/bugs/1716493>
<mup> Bug #1716493 changed: Machine ownership visibility option <MAAS:New> <https://launchpad.net/bugs/1716493>
<mup> Bug #1716494 opened: Admin certificate upload <MAAS:Incomplete> <https://launchpad.net/bugs/1716494>
#maas 2017-09-12
<jamesbenson> morning everyone
<jamesbenson> I am using maas v.2.2.2 (previously used 2.1.5) and I can't seem to commission any of my servers any more.  Through idrac, I see it fails the ntpd and stops at the boostrap login.  Any suggestions?
<roaksoax> jamesbenson: how does it fail ? do you have the latest images ?
<jamesbenson> roaksoax: I believe so, the images are all synched.  I'm not sure how else to check if it failed since I can't even ssh into the machines only able to view them from idrac...
<jamesbenson> 16.04 LTS, amd64 on Dell R610, Dell R710, and Dell R410.
<jamesbenson> is what I'm trying to get up and running again.
<jamesbenson> I did an upgrade from 2.1.5 to 2.2.2 and didn't seem to work, so I deployed another VM with maas fresh with 2.2.2 and tried, failed as well, same issues.
<roaksoax> jamesbenson: if you could share the error that you see in the console, it would be great
<jamesbenson> roaksoax: I can even do a screen share if you want :-)
<roaksoax> jamesbenson: no need for screenshare, but a screenshout would be ok
<jamesbenson> https://pasteboard.co/GK2v5gG.png
<roaksoax> jamesbenson: that seems like it booted into centos
<jamesbenson> yes, which royally confuses me....
<jamesbenson> I only have ubuntu selected....
<roaksoax> jamesbenson: so was this machine previously installed with centos ?
<roaksoax> jamesbenson: is this machine UEFI ?
<jamesbenson> nope, ubuntu.
<jamesbenson> bios
<jamesbenson> I can make it uefi if needed.
<jamesbenson> in images and settings, only ubuntu 16.04LTS is selected, cent is not selected anywhere.
<roaksoax> jamesbenson: what it looks to me is as if centos is installed on the disk, and the machine failed to PXE boot
<jamesbenson> Actually I re-did the raid as well, so it is completely clean
<roaksoax> rigt, but if you have no centos images in maas
<roaksoax> there's no reason why it should boot centos
<jamesbenson> it pxe's, I've watched it... it shows
<roaksoax> jamesbenson: can you record a video of the whole process ?
<jamesbenson> i know, I was very confused as why maas is using cent
<jamesbenson> :-/. recommended product?
<jamesbenson> and this centos thing is happening with ::all:: of the ones I try to commission.  (We only use ubuntu here).
<jamesbenson> roaksoax, I PM'ed you a viewing option.
<jamesbenson> Trying to record something now.
<jamesbenson> I'm going to upload it to youtube...
<jamesbenson> server is still booting.
<mup> Bug #1716750 opened: VM deployed by MAAS has limited network functionality <onsite> <MAAS:Incomplete> <https://launchpad.net/bugs/1716750>
<mup> Bug #1716784 opened: Ephemeral boot error: alloc magic is broken at 0x94eceac0: 94e05880 <MAAS:New> <https://launchpad.net/bugs/1716784>
<mup> Bug #1716784 changed: Ephemeral boot error: alloc magic is broken at 0x94eceac0: 94e05880 <MAAS:New> <https://launchpad.net/bugs/1716784>
<mup> Bug #1716784 opened: Ephemeral boot error: alloc magic is broken at 0x94eceac0: 94e05880 <MAAS:New> <https://launchpad.net/bugs/1716784>
#maas 2017-09-13
<Guest73708> I have configured custom repo for my MAAS cluster, and want to import custom kernel into the MAAS custom repo.  Does someone know of tools through which image can be imported?  Does it need GPG signing? Any steps on how it needs to be configured?
<Guest73708> posting it again, since I didn't get any response earlier
<Guest73708> just checking if some folks are still active
<mup> Bug #1716894 opened: When trying to enable DHCP on a vlan with unmanaged subnets the message is confusing <MAAS:New> <https://launchpad.net/bugs/1716894>
<roaksoax> Guest73708: custom kernels are not supported in MAAS, so dunno whether it would work well for you. But typucally, if you point to a image mirror, then you dont need new gpgp syncing
<roaksoax> Guest73708: you could try pointing to the index.json, but obviously your images wont be verified
<Guest73708> #roaksoax: well, I am not sure what you mean by pointing to index.json file?
<Guest73708> using simplestreams I created a mirror image
<Guest73708> and now want to add my image into the local mirror repo
<Guest73708> I thought that was the use of custom repo, otherwise, I don't see any significant use of a custom repo
<Guest73708> just having local copy is fine, but real value addition would be if we can add custom images as well
<Guest73708> I can try signing my images as well if required
<roaksoax> Guest73708: the streams will have a index.json, which is not signed, which you could point maas at
<roaksoax> Guest73708: the local mirror of images is to deal with offline environments where maas doesn't have access to the internet
<roaksoax> Guest73708: that said, you upload your own custom images to maas though
<Guest73708> through?
<roaksoax> Guest73708: maas admin boot-resources name=custom/your-ubuntu arch=amd64 content@=/your/custom/image filetype=tgz
<roaksoax> Guest73708: for example
<Guest73708> roaksoax: that is importing complete image. Probably I do not want to go that route.
<jamesbenson> morning all :-)
<roaksoax> jamesbenson: morning!
<jamesbenson> morning, it looks like deployment still fails with GPT on drives still greater than 2TB
<jamesbenson> I'm trying on a different R710 to verify, but looks like it gives me the same errors
<jamesbenson> roaksoax: ^
<roaksoax> jamesbenson: it seems that we'll hav eto investigate
<roaksoax> jamesbenson: do you have a installation log to see the failure ?
<jamesbenson> I can pull them, where are they?
<jamesbenson> I'm hoping it isn't this bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1284196
<roaksoax> jamesbenson: you can grab the UI , on the machine details page there should be "Installation log" or something
<roaksoax> along the lines
<roaksoax> jamesbenson: you usnig 2.2.2 right ?
<jamesbenson> roaksoax: yes I am.  https://pastebin.com/4YdiSBmF
<jamesbenson> roaksoax: also my "trick" of manually creating the 3 partitions, didn't work.  Still facing a "attempt to read or write outside of disk 'hd0' Entering rescue mode..." error
<jamesbenson> roaksoax: thoughts?
<roaksoax> jamesbenson: strange, your pastebin shows as it deployed correctly
<roaksoax> but on reboot, grub didn't boot onto the disk ?
<jamesbenson> nope, I get the error mentioned above.
<jamesbenson> This is on all of my machines over 2TB
<roaksoax> jamesbenson: right, when does that error happen ?
<jamesbenson> after installation is complete and it reboots
<jamesbenson> upon reboot it goes straight into that
<jamesbenson> did you want me to record again?
<jamesbenson> I can show you the whole process if you want
<roaksoax> jamesbenson: ok, this is legacy mode right ?
<roaksoax> jamesbenson: i mean, machines are booting in legacy, not EFI
<jamesbenson> yes, bios, not uefi
<roaksoax> jamesbenson: ok, so, how many disks do you hav ein that machine ?
<jamesbenson> I have 6 disks but they go through our perc6/i raid controller
<jamesbenson> as raid 6, so maas only see's 1 HD
<jamesbenson> each drive is 2tb
<jamesbenson> individually
<jamesbenson> roaksoax: ^^
<roaksoax> jamesbenson: and, is the bios boot order configured in a way that it would boot off a single specific disk ?
<jamesbenson> no, boots only from pxe
<jamesbenson> pxe controls if it goes to disk or not
<jamesbenson> want me to try with uefi?
<jamesbenson> roaksoax: ^^
<jamesbenson> roaksoax: attempting with uefi....
<roaksoax> jamesbenson: right, but after maas installation, the machine reboots, it will pxe, and it will be told to localboot, and it could be attempting to localboot from a different disk from where the OS has been installed
<jamesbenson> I don't think so, maas and raid both tell it there is only 1 disk
<jamesbenson> roaksoax: I've manually installed ubuntu before and it also only detects 1 disk in this situation
<roaksoax> jamesbenson: yup, that's what i would have expected as well
<jamesbenson> roaksoax: so in that regard all information is consistent.
<roaksoax> jamesbenson: did it work with efi ?
<jamesbenson> roaksoax: just finishing now
<jamesbenson> roaksoax: failed.  https://pastebin.com/6SkfYmFj
<roaksoax> jamesbenson: please file a bug against both 'maas' & 'curtin', attach the installation log
<roaksoax> jamesbenson: and the output of: maas <user> machine get-curtin-config <system-id>
<roaksoax> jamesbenson: also, there's recetnly been a grub upgrade that could or may be the culprit of this
<jamesbenson> roaksoax: Summary: bios/efi maas deployment failure with drives over 2TB?
<roaksoax> jamesbenson: yup
<jamesbenson> roaksoax : How do I put this bug against both maas and curtin?
<jamesbenson> tags?
<roaksoax> jamesbenson: just file it against MAAS< I'll deal with adding curtin to it
<roaksoax> :)
<jamesbenson> lol okay, sorry
<roaksoax> jamesbenson: there's some button there that says "add project"
<roaksoax> actually
<roaksoax> "also affects projecT"
<jamesbenson> having issue finding the system-id of this machine...
<jamesbenson> it doesn't like the name I gave it.
<roaksoax> jamesbenson: it should be in the URL
<jamesbenson> gotcha
<jamesbenson> thanks
<jamesbenson> should I modify the token & token_secret?
<roaksoax> jamesbenson: nah, those get automatically generated so I dont think you would, but go ahead jus in case :)
<jamesbenson> roaksoax: https://bugs.launchpad.net/curtin/+bug/1717031
<roaksoax> jamesbenson: thanks!
<mup> Bug #1717031 opened: bios/efi maas deployment failure with drives over 2TB <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1717031>
<jamesbenson> roaksoax: my pleasure!  I hope this can get fixed quickly.  I'm going to have to roll back until we can actually deploy.  :-(
<roaksoax> jamesbenson: it doesn't work even with your paritioning ?
<roaksoax> i wonder if this is a grub issue
<jamesbenson> roaksoax: no it doesn't
<jamesbenson> roaksoax: again worked under 2.1.5 though
<jamesbenson> with my partitioning and bios
<roaksoax> jamesbenson: same verion of image s?
<jamesbenson> yes
#maas 2017-09-14
<mup> Bug #1717189 opened: Commision runs lsblk wit hunknown option <MAAS:New> <https://launchpad.net/bugs/1717189>
<mup> Bug #1717176 opened: Fail to install or commission wichita (power 8) <MAAS:New> <curtin (Ubuntu):Invalid> <https://launchpad.net/bugs/1717176>
<mup> Bug #1717176 changed: Fail to install or commission wichita (power 8) <MAAS:New> <curtin (Ubuntu):Invalid> <https://launchpad.net/bugs/1717176>
<mup> Bug #1717176 opened: Fail to install or commission wichita (power 8) <MAAS:New> <curtin (Ubuntu):Invalid> <https://launchpad.net/bugs/1717176>
<bryanb229> hello wondering if anyone has successfully been able to deploy centos 7 with an out of the box maas installation
<bryanb229> ive been trying for many months but it keeps hanging on the web ui
<bryanb229> as it relates to this bug https://bugs.launchpad.net/maas/+bug/1627441
<mwe1> @bryanb229: if your servername is 'localhost' after install: can you ensure there is no network related issue? DNS, etc...
<bryanb229> @mwe1 i dont think its a dns issue b/c centos 6 and ubuntu installs work fine, its just centos 7 that is not working
<jamesbenson> rharper: ping
<mup> Bug #1717269 opened: [Documentation] Intro concepts page issues <MAAS:New> <https://launchpad.net/bugs/1717269>
<jamesbenson> rharper: ping
<rharper> jamesbenson: here
<jamesbenson> hey, have time for a quick chat about bug 1717031?
<jamesbenson> I booted back into my maas v2.1.5 node to recommission this machine, but still no luck with uefi.
<jamesbenson> I'm going to go back to v2.2.2.  In regards to your comment about BIOS booting with GPT.  We need to create that partition? Because I've never seen it.
<rharper> sure
<rharper> You shouldn't need to make changes manually, maas should know how to do GPT partitions for large drives;
<jamesbenson> okay
<rharper> I'm not familiar with the maas UI on what might need to change
<jamesbenson> with bios, it detects the gpt, but there is only the one partition /
<rharper> but generally, if MAAS knows it's GPT, it should automatically create the config to include the 1MB linux-bios partition (and set the flag)
<rharper> it might not show you it in the UI;  but again I'm not for sure (I work on the curtin installer which consumes the config that maas sends)
<jamesbenson> regardless of eufi or bios?
<jamesbenson> okay
<jamesbenson> do you know the cli off hand to verify?
<rharper> for UEFI, it has a /boot/EFI partition instead of a linux bios partition
<rharper> yeah, let's run that command to extract the curtin config
<catbus> need to recommission the machine if bios boot mode is changed, so maas will set the partition accordingly.
<rharper> maas <session> machine get-curtin-config <system-id>
<rharper> I think that should dump the config; and I can help verify
<jamesbenson> okay, thanks guys.  I just switched it back to bios.
<jamesbenson> I'll recommission now and get back to you in a few when it is finished.
<rharper> jamesbenson: ok
<jamesbenson> looks like that partition is there: https://pastebin.com/qZJphMhY   I'm deploying now to see how it goes.
<alopez> hi, i need add a node that has already SO installed and has partition into maas server
<alopez> is this possible ?
<jamesbenson> rharper & catbus: installation was "successful" however, boot goes into grub rescue.
<rharper> jamesbenson: what release are you installing ? Xenial ?
<jamesbenson> maas v2.2.2 and 16.04 LTS
<catbus> what's the error before it drops to grub rescue?
<jamesbenson> Kernel: xenial (ga-16.04)  OS: Ubuntu 16.04 LTS "Xenial Xerus"
<jamesbenson> error: attempt to read or write outside of disk 'hd0'
<rharper> interesting
<alopez> anyone knows how to do this ?
<catbus> jamesbenson: the boot disk drive is >2TB I assume?
<jamesbenson> yes: Storage 7999.4GB over 1 disks
<jamesbenson> It does pick up that it is a PERC 6/i card...
<rharper> what sort of raid mode?  I don't think it matters; and it should work
<jamesbenson> Raid 6
<rharper> but the error message seems to imply the sector where the grub config is beyond the grub limit;  just looking around for more information
<catbus> jamesbenson: could you try this? Create a partition for '/' with 'ext4' under sda in the node page, re deploy.
<jamesbenson> Found initrd image: /boot/initrd.img-4.4.0-93-generic
<jamesbenson>   /run/lvm/lvmetad.socket: connect failed: No such file or directory
<jamesbenson>   WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
<jamesbenson> done
<jamesbenson> In the installation logs it shows:
<catbus> IIRC, the bios boot mode supports up to 2TB.
<jamesbenson> catbus: that's what it is currently
<catbus> jamesbenson: sorry, set the partition size to 1TB.
<jamesbenson> ok
<jamesbenson> releasing and re-deploying with that partition.
<catbus> uefi boot mode is designed to support drive >2TB, the limitation of the legacy bios mode.
<rharper> GPT handles >2TB fine ; I don't think the size is the issue here
<jamesbenson> catbus: we have always used bios and been able to use the full drive without issues.... It may not have been only one partition, not sure.  But maas doesn't even deploy with uefi.  But I would love to get this figured out....
<rharper> we could create a /boot partition ; that might ensure that the /boot directory location on the root partition isn't too far
<jamesbenson> rharper, that's what I did initially
<jamesbenson> in the bug report.
<jamesbenson> That's what I did in v2.1.5 to make it work
<jamesbenson> 1GB /boot; 4GB SWAP; 8TB /
<jamesbenson> but in 2.2.2 this doesn't wokr
<jamesbenson> work
<rharper> y; the original failure looked to be related to maas not knowing which boot mode you were in (UEFI vs. BIOS)
<jamesbenson> No, I was attempting all methods that "should work", none did.
<jamesbenson> :-(
<rharper> that seems to been in sync now after commissionion;  the UEFI shimx64 missing looked to be related to maybe secure-boot being enabled, but I don't know if it's only an issue with SB;  the grub2 package install should do the right thing and ensure shim is installed
<jamesbenson> We don't use secure boot.  But I will double check that it is disabled.  Currently I'm trying to deploy with the 1TB / with BIOS.
<jamesbenson> FWIW: I'm willing to have someone remote login/view as well to check things out.
<catbus> Let's see if 1TB / with BIOS works first.
<catbus> UEFI should just work without any change on the partition table configured by MAAS after recommissioning. Or you may check if there is newer firmeware/BIOS.
<jamesbenson> firmware/bios is latest on every piece of hardware.... I spent way too much time doing that...
<catbus> ok
<catbus> jamesbenson: is your server one of the 16.04 certified models here: https://certification.ubuntu.com/server/?
<jamesbenson> .... no.
<jamesbenson> we have dell r410, r610, r710, r910... this one is a r710.
<jamesbenson> I see the r410 & r610 are there, but not the 710&910....
<jamesbenson> I see it is compatible with 14.04
<catbus> ok.
<jamesbenson> and our raid controller is not on that list for the r710
<catbus> Is the installation done yet?
<jamesbenson> sorry I got stuck with the secure boot to see if it is enabled.  It's not available when you're in BIOS, needs to be UEFI.  Going back to deployment.
<jamesbenson> maas did say the curtin was finished.
<jamesbenson> I think it worked, but I'm having issues SSH'ing into the machine...
<jamesbenson> success with the 1TB /
<jamesbenson> catbus: ^^
<rharper> jamesbenson: \o/
<jamesbenson> so the question then, where is the bug?
<jamesbenson> catbus, rharper: idea's?
<catbus> jamesbenson: did the server boot up fine?
<jamesbenson> yes with the 1TB /
<catbus> jamesbenson: I assume that you have tried UEFI boot mode, recommission, and deploy, and it failed, what's the failure?
<catbus> jamesbenson: BIOS (Legacy) boot mode uses MBR which doesn't support >2TB boot drive. UEFI boot mode uses GPT which supports boot drive >2TB.
<jamesbenson> yes, I've tried UEFI boot following that procedure.  The failure is: error: no such device: /efi/ubuntu/shimx64.efi
<jamesbenson> catbus: installation is successful, on reboot that error occurs
<jamesbenson> error: File not found.
<rharper> the UEFI-mode missing shim is a grub2 bug;  it's not yet know what the root cause for grub2 installation failing to install the  shimx64 file;  that needs following up; in your case, you're not using SecureBoot, that's an additional data point for that bug
<jamesbenson> I'm enable UEFI and double check, but we shouldn't be using it.
<rharper> w.r.t BIOS and 8TB drive, I think the /boot partition (rather than just a smaller than 2TB /) should work;  the message from grub about read failures is likely due to the location of where grub configuration files ended up on the disk;  a smaller dedicated /boot in addition to the / partition should work;
<jamesbenson> s/I'm/I'll/
<jamesbenson> I'll try that again.  I tried it before and it failed, but who knows.  I'll try again.
<catbus> agreed re: a smaller dedicated /boot in addition to the / partition should work.
<jamesbenson> 1GB /boot should be more than enough correct?
<rharper> jamesbenson: ok;  I think we'll collect the data from today an update the bug, we can check in with the grub/efi folks to see if something else is going one (and if they have any steps to try once in the failing state to help isolate where the failure is; say firmware or  grub2 ,etc)
<rharper> yeah
<jamesbenson> sounds good.  I'm keeping v2.2.2 so feel free to message me if you need data.  Fixing this bug helps the community and me.  :-)
<jamesbenson> rharper catbus: just deployed with BIOS, 1GB /boot 8GB SWAP 8TB / and it somehow worked.  doing a fdisk -l, I can see a 1M BIOS boot partition there as well.
<rharper> \o/
<mup> Bug #1717348 opened: Query iLO/iDRAC/BMC hostname/servername to set node name during enlisting instead of generating $random-$random name <MAAS:New> <https://launchpad.net/bugs/1717348>
<mup> Bug #1717287 opened: maas-enlist doesn't work when provided with serverurl with IPv6 address <MAAS:New> <maas-enlist (Ubuntu):New> <https://launchpad.net/bugs/1717287>
#maas 2017-09-15
<mup> Bug #1717176 changed: Fail to install or commission wichita (power 8) <MAAS:Invalid> <curtin (Ubuntu):Invalid> <https://launchpad.net/bugs/1717176>
<mup> Bug #1717511 opened: MAAS 2.2.2 do not honor network configuration in rescue mode <MAAS:New> <https://launchpad.net/bugs/1717511>
<mup> Bug #1717543 opened: [FFe] Standing Feature Freeze Exception for MAAS 2.3 <MAAS:New> <https://launchpad.net/bugs/1717543>
<Neeraj> Hi
<Neeraj> I need some information.. regarding maas
<Neeraj> Can i manage my physical datacenter with the help of maas
<jamesbenson> Neeraj, that's what we do.   Sort of the point?
<jamesbenson> Random Q: Do you guys use hardware raid or software raid in production?  I'm torn between what we traditionally have used, raid 5/6, and software raid/zfs... I think I'll need to do some testing for our situation  and performance testing, but wanted thoughts.
<roaksoax> jamesbenson: while I dont deloy a lot of raid, i've heard a lot of mixed ways of doing things
<roaksoax> jamesbenson: some like hw raid better than sw raid and vice versa
<bdx> will maas recognize a satadom as a disk device ... it should righ?
<roaksoax> bdx: if that's surfaced to the OS as a disk, it should yes
<mup> Bug #1717612 opened: MAAS uses region IP address for default DNS servers, but DNS is provided by rack controllers <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1717612>
#maas 2017-09-16
<mup> Bug #1703689 changed: [2.2.1] When deploying servers with VLAN using IPv6 alias ifdown fails with cannot find device <curtin:Incomplete> <MAAS:Expired> <https://launchpad.net/bugs/1703689>
<mup> Bug #1717669 opened: Ephemeral boot has broken DNS <MAAS:New> <https://launchpad.net/bugs/1717669>
#maas 2017-09-17
<mup> Bug #1459432 changed: "could not serialize access due to concurrent update" errors in PostgreSQL logs <MAAS:Expired> <https://launchpad.net/bugs/1459432>
#maas 2019-09-09
<atdprhs> Hello everyone, I keep getting the following error >> No available machine matches constraints: [('agent_name', ['93d500ee-7e14-4ece-81ae-69137d451f3a']), ('storage', ['root:0,27:32,28:32,29:8']), ('zone', ['default'])] (resolved to "storage=root:0,27:32,28:32,29:8 zone=default")
<atdprhs> can anyone please help?
<atdprhs> anyone available?
<mup> Bug #1843266 opened: Add support for tar.xz images <curtin:New> <MAAS:Triaged> <https://launchpad.net/bugs/1843266>
<mup> Bug #1843268 opened: maas become unresponsive with maasserver_notification stuck at concurrent update <MAAS:New> <https://launchpad.net/bugs/1843268>
#maas 2019-09-10
<mup> Bug #1843493 opened: Intermittent DB failure when creating VM pods via post /MAAS/api/2.0/machines/?op=allocate <MAAS:New> <https://launchpad.net/bugs/1843493>
#maas 2019-09-11
<atdprhs> hello everyone, juju deploy works perfect with everything except when I try to deploy ceph-osd, I usually get `"failed to start machine 15 (failed to acquire node: No available machine matches constraints: [('agent_name', ['623fe854-6d68-463d-8337-73ce136cc4bb']), ('storage', ['root:0,0:32,1:32,2:8']), ('zone', ['default'])] (resolved to
<atdprhs> "storage=root:0,0:32,1:32,2:8 zone=default")), retrying in 10s (10 more attempts)"
<atdprhs> This is following https://ubuntu.com/kubernetes/docs/storage / `juju deploy -n 3 ceph-osd --storage osd-devices=32G,2 --storage osd-journals=8G,1`
<atdprhs> Do anyone know if I'm missing any config on maas?
<atdprhs> from my knowledge, storage pool default has a lot of free space
<atdprhs> and I don't know how to troubleshoot this
<atdprhs> rick_h I figured why I had a lot of VMs
<atdprhs> when I run `juju deploy -n 3 ceph-osd --storage osd-devices=32G,2 --storage osd-journals=8G,1`, I am expecting 3 instances of `ceph-osd`, it fails to start `failed to start machine 15 (failed to acquire node: No available machine matches constraints: [('agent_name', ['623fe854-6d68-463d-8337-73ce136cc4bb']), ('storage', ['root:0,0:32,1:32,2:8']),
<atdprhs> ('zone', ['default'])] (resolved to "storage=root:0,0:32,1:32,2:8 zone=default")), retrying in 10s (10 more attempts)` and it runs `10 attempts`
<atdprhs> 3*10 ==> 30 instances + the original 3 so 33
<atdprhs> I have 33 instances now to clean up!
<atdprhs> lol
<rick_h> atdprhs:  ouch, wow
#maas 2019-09-12
<mup> Bug #1843677 opened: pod refresh fails with gluster storage pool <gluster> <kvm> <pod> <MAAS:New> <https://launchpad.net/bugs/1843677>
<mup> Bug #1710278 opened: [2.3a1] named stuck on reload, DNS broken <sts> <BIND:New> <MAAS:Fix Committed by blake-rouse> <MAAS 2.2:Fix Released by blake-rouse> <MAAS 2.6:Fix Committed by blake-rouse> <MAAS 2.7:Fix Committed by blake-rouse> <bind9 (Ubuntu):In Progress> <maas (Ubuntu):New> <bind9 (Ubuntu
<mup> Xenial):In Progress> <bind9 (Ubuntu Bionic):In Progress> <maas (Ubuntu Bionic):New> <bind9 (Ubuntu Disco):In Progress> <bind9 (Ubuntu Eoan):In Progress> <https://launchpad.net/bugs/1710278>
<pepperhead> Good Morning!
<pepperhead> I have a quick question: It appears in the maas docs mention that maas can only deploy a windows image if you have Ubuntu Advantage? https://maas.io/docs/images
<pepperhead> Am I reading that correctly?
<pepperhead> Can maas deploy microsft windows to a machine?
<mup> Bug #1843759 opened: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<ociuhandu> pepperhead: as long as you upload the correctly-built disk image, MaaS will deploy it
<pepperhead> So my current .ami probably needs rebuilt?
<ociuhandu> you need a disk image
<ociuhandu> full with partitions and everything required
<pepperhead> Does anyone have a link to recent directions on that process? I found this, but its a few years old https://web.sas.upenn.edu/jasonrw/2016/03/01/how-to-create-a-windows-image-for-mass-deployment/
<pepperhead> oops, that mass, not maas
<mup> Bug #1843759 changed: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<mup> Bug #1843759 opened: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<ociuhandu> pepperhead: there is a project for that, https://github.com/cloudbase/windows-openstack-imaging-tools
<pepperhead> GRATZI!
<pepperhead> Looks like the resulting image can be used by both maas and openstack?
<ociuhandu> pepperhead: Ubuntu Advantage and similar services are recommended for production environments in order to have support for building and deploying the images
<pepperhead> Which makes senses, I geuss openstack just creates a blank "machine" and images it.
<ociuhandu> pepperhead: the tools can generate maas and openstack images
<ociuhandu> there are some differences between them in terms of requirements for initial boot initialization
<ociuhandu> like metadata source for credentials / certificates, network config info etc
<pepperhead> I am trying to wrap my head around on prem devops/testing and looking to build a POC to get management on board. Just need to spin a windows box, DL and install my application and gradle, and run a gradle command.
<mup> Bug #1843759 changed: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<pepperhead> so many options, and I am not familiar with any of them. Saltstack, Openstack, maas/juju, all the hypervisors out there now.
<pepperhead> I was hired as an AWS guy, but they want testing in an on prem solution for cost reasons...
<mup> Bug #1843759 opened: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<pepperhead> The smartest question I should ask you in the know is : am I going down the right road with MaaS?
<mup> Bug #1843759 changed: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<mup> Bug #1843759 opened: Malformed JSON in test script parameters <MAAS:New> <https://launchpad.net/bugs/1843759>
<mup> Bug #1843771 opened: [UI 2.6.1] Show all XXX... displaying incorrectly <ui> <MAAS:Triaged by blr> <https://launchpad.net/bugs/1843771>
<mup> Bug #1843771 changed: [UI 2.6.1] Show all XXX... displaying incorrectly <ui> <MAAS:Triaged by blr> <https://launchpad.net/bugs/1843771>
<mup> Bug #1843771 opened: [UI 2.6.1] Show all XXX... displaying incorrectly <ui> <MAAS:Triaged by blr> <https://launchpad.net/bugs/1843771>
<mup> Bug #1843771 changed: [UI 2.6.1] Show all XXX... displaying incorrectly <ui> <MAAS:Triaged by blr> <https://launchpad.net/bugs/1843771>
<mup> Bug #1843771 opened: [UI 2.6.1] Show all XXX... displaying incorrectly <ui> <MAAS:Triaged by blr> <https://launchpad.net/bugs/1843771>
<mup> Bug #1843780 opened: [2.6] boot-resource is-importing reports true when importing is finished <MAAS:New> <https://launchpad.net/bugs/1843780>
#maas 2019-09-13
<mup> Bug #1843855 opened: python3-django-maas depends on python3-convoy, removed from Debian unstable <maas (Ubuntu):New> <https://launchpad.net/bugs/1843855>
<mup> Bug #1843856 opened: Deployment fails when DCHP addresses used during deployment are different than static address provided afterwards. <MAAS:New> <https://launchpad.net/bugs/1843856>
<mup> Bug #1843855 changed: python3-django-maas depends on python3-convoy, removed from Debian unstable <maas (Ubuntu):New> <https://launchpad.net/bugs/1843855>
<mup> Bug #1843856 changed: Deployment fails when DCHP addresses used during deployment are different than static address provided afterwards. <MAAS:New> <https://launchpad.net/bugs/1843856>
<mup> Bug #1843855 opened: python3-django-maas depends on python3-convoy, removed from Debian unstable <maas (Ubuntu):New> <https://launchpad.net/bugs/1843855>
<mup> Bug #1843856 opened: Deployment fails when DCHP addresses used during deployment are different than static address provided afterwards. <MAAS:New> <https://launchpad.net/bugs/1843856>
<mup> Bug #1843919 opened: nginx has incorrect path for machine-resources in Debian package <MAAS:Triaged> <https://launchpad.net/bugs/1843919>
<mup> Bug #1843919 changed: nginx has incorrect path for machine-resources in Debian package <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1843919>
<mup> Bug #1843919 opened: nginx has incorrect path for machine-resources in Debian package <MAAS:In Progress by newell-jensen> <https://launchpad.net/bugs/1843919>
