[00:17] <melmoth> is rebooting a zookeeper node on a maas installation supposed to work ?
[00:18] <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
[00:18] <lifeless> thats more a #juju question, sorry!
[00:18] <lifeless> SpamapS: ^
[00:18] <melmoth> zookeeper runs, but it s log does mention thing likes "xpiring session 0x139bcf841700004, timeout of 10000ms exceeded"
[00:20] <SpamapS> as long as the address doesn't change, you should be able to reboot node 0
[00:20] <SpamapS> agents should poll/reconnect eventually
[00:20] <melmoth> thanks.
[00:21] <smoser> roaksoax, around ?
[00:31] <smoser> jtv, https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083
[00:34] <smoser> roaksoax, ^ for you too.
[00:38] <bigjools> smoser: I'll look
[00:43] <bigjools> smoser: do you need something to uninstall all that when the package is removed?
[00:45] <smoser> well ther ei sonly the one thing installed, and its will be removed just as any other file
[00:45] <smoser> the one thing ... /etc/apparmor.d/dhcpd.d
[00:46] <bigjools> smoser: ok - I didn't know if it was automatically removed or not
[00:46] <bigjools> smoser: can you do a packaging.precise merge as well please
[00:46] <smoser> yeah, its just a file.
[00:47] <smoser> ackaging.precise will depend on sru of the isc-dhcp fix also.
[00:47] <bigjools> yeah
[00:47] <smoser> and i'd like to wait until this at least is baked a bit before uploading that.
[00:47] <bigjools> yup
[00:48] <smoser> tomorrow i'll try to do a pakaging merge for precise though and just have the mp ready
[00:49] <bigjools> cool
[02:19] <jtv> Thanks smoser!
[02:23] <bigjools> hello jtv
[02:23] <jtv> Hi
[02:30] <jtv> bigjools: saw that email where DEFAULT_MAAS_URL turns out to tie into the UI somehow.  Damnation.
[02:30] <bigjools> jtv: yes - I asked diogo exactly how it breaks
[02:30] <bigjools> damnation indeed
[02:30] <jtv> No idea where that happens.
[02:30] <bigjools> back to the drawing board for you :)
[02:31] <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
[02:31] <jtv> Hi there matsubara
[02:31] <matsubara> jtv, hey
[02:32] <bigjools> hey matsubara
[02:32] <jtv> Hmmm... this sounds as if the connection between UI and the setting is made in the packaging somewhere.
[02:32] <bigjools> that's a bizarre thing for the web server to do
[02:32] <bigjools> sounds like packaging
[02:32] <jtv> Yup.
[02:32] <jtv> It should definitely be listening on both interfaces.
[02:32] <bigjools> not sure why we need to tell apache where to listen, all interfaces seems more reasonable to me
[02:32] <jtv> Because it must service both you (the human) and the workers/nodes in the MAAS.
[02:32] <bigjools> yeah
[02:34] <matsubara> bigjools, jtv: when I run dpkg-reconfigure maas, it stops the apache server but doesn't restart it again
[02:34] <bigjools> matsubara: haha!
[02:35] <jtv> That does kind of explain...
[02:35] <matsubara> in any case it looks like a bug, reconfigure should restart apache, shouldn't it?
[02:35] <bigjools> yes
[02:35] <bigjools> not sure why it needs to restart it at all
[02:36] <matsubara> it stops it for some reason :-)
[02:36] <bigjools> if you restart it, does the UIU and everything else work?
[02:36] <bigjools> UI*
[02:37] <jtv> I wonder where it stops apache...  it seems to be only the postinst and such that mess with apache.
[02:38] <matsubara> yes, restarting it seems to bring the UI back up
[02:38] <roaksoax> matsubara: there's a bug where reconfigure does not restart apache and I'll deal with that
[02:39] <jtv> \o/
[02:39] <bigjools> woo
[02:39]  * bigjools heads out to lunch
[02:39] <jtv> roaksoax: out of interest, where does it stop apache?  I would have expected to see that in maas.config.
[02:39] <jtv> (Because I'm not a packaging expert)
[02:40] <roaksoax> jtv: we don't stop apache2
[02:40] <roaksoax> jtv: maybe it is crashing for some reason? the restart stops and start the daemon agian
[02:40] <roaksoax> maybe that is it?
[02:40] <jtv> Ohhhh
[02:40] <roaksoax> jtv: no error logs?
[02:40] <roaksoax> apache2 error logs that is
[02:40] <jtv> Ask matsubara :)
[02:40] <roaksoax> matsubara: http://paste.ubuntu.com/1201757/
[02:40] <roaksoax> matsubara: try that
[02:41] <jtv> I guess it's just a way to restart the wsgi processes..?
[02:41] <roaksoax> matsubara: can you, however, directly point me to bugs or issues you find with packaging otherwise I'll lots in bugmail
[02:41] <roaksoax> jtv: yes
[02:42] <roaksoax> jtv: so dpkg-reconfigure maas, change IP should restart apache2 to pick the new IP and things should be just fine
[02:42] <roaksoax> matsubara: ^^
[02:42] <jtv> Wait... what new IP?
[02:42] <jtv> Apache should be listening on all interfaces.
[02:42] <jtv> MAAS must be aware of the new address, but not apache, right?
[02:43] <roaksoax> jtv: yes, it is for maas to pick up the new IP
[02:43] <roaksoax> and stuff
[02:43] <matsubara> roaksoax, I'm looking at the apache logs. let me paste it for you
[02:44] <roaksoax> jtv: the dpkg-reconfigure maas sets a new ip in DEFAULT_MAAS_URL
[02:44] <roaksoax> s/in/for
[02:44] <matsubara> roaksoax, https://pastebin.canonical.com/74380/
[02:45] <roaksoax> matsubara: do you have a  node deployed where I can test?
[02:45] <roaksoax> matsubara: err log in and test?
[02:45] <roaksoax> that's maybe upstream error
[02:45] <matsubara> roaksoax, the maas server is running but there's no node deployed
[02:46] <roaksoax> matsubara: yeah can you tell me your steps to reproduce the issue you encountereD?
[02:46] <matsubara> roaksoax, sudo dpkg-reconfigure maas
[02:46] <matsubara> change the ip
[02:46] <matsubara> the apache server is stopped but not restarted
[02:47] <matsubara> feel free to log in the Lenovo lab
[02:47] <matsubara> https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab
[02:47] <roaksoax> matsubara: yeah that's a bug
[02:48] <roaksoax> matsubara: there's a restart_apache2 missing on dpkg-reconfigure
[02:48] <roaksoax> matsubara: http://paste.ubuntu.com/1201757/
[02:49] <matsubara> I see
[02:50] <roaksoax> matsubara: try now
[02:50] <matsubara> is it a known bug?
[02:50] <roaksoax> matsubara: yes it is a known bug, I will fix it tomorrow
[02:50] <roaksoax> matsubara: i was concentrated on getting the releases support into maas
[02:51] <roaksoax> matsubara: pastebin /etc/maas/maas_local_settings.py after the dpkg-reconfigure
[02:51] <matsubara> roaksoax, yes, now it restarted fine
[02:52] <roaksoax> matsubara: alright cool then
[02:52] <matsubara> roaksoax, do you still need that pastebin?
[02:52] <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
[02:52] <roaksoax> matsubara: nah!
[02:53] <matsubara> cool. thanks
[02:53] <roaksoax> matsubara: i'm sure the above fix has fixed things
[02:57] <roaksoax> jtv: so can we ship our own maas-dhcp upstart job then?
[02:57] <smoser> roaksoax, fwiw, there are python bindings to distro-info
[02:57] <jtv> And hi smoser
[02:57] <smoser> roaksoax, yeah you can do that.
[02:57] <smoser> (i'm not really here)
[02:57] <jtv> That explains.
[02:57] <roaksoax> smoser: python-bindings as in import DistroINfo etc etc or similar?
[02:58] <smoser> right
[02:58] <jtv> roaksoax: I have a handy example of a modified upstart job if you want it.
[02:58] <roaksoax> smoser: ah cool, willk use that intstead then
[02:58] <roaksoax> jtv: sure, i wont merge it tonight though as I'm in zombie mode
[02:58] <roaksoax> but will do tomorrow
[02:58] <roaksoax> i'd like to get this fixed tomorrow
[02:58] <jtv> @#$% timezones
[02:58] <jtv> I'd be most grateful.  Hang on, I'll paste my upstart script.
[02:59] <smoser> roaksoax, http://paste.ubuntu.com/1201799/
[02:59] <smoser> thats a patch to cobbler that i used to use it there.
[02:59] <smoser> might just get you started
[02:59] <smoser> but its very simple
[02:59] <roaksoax> smoser: nice, thanks!
[03:00] <jtv> roaksoax: I named it maas-dhcp-server — http://paste.ubuntu.com/1201804/
[03:00] <roaksoax> jtv: awesome, will merge it tomorrow and test
[03:00] <jtv> Thanks!  We'll need to make corresponding changes to trunk as well, as we need to restart dhcpd.
[03:01] <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
[03:01] <roaksoax> and we should be good
[03:01] <jtv> \o/
[03:01] <jtv> Thanks again.
[03:02] <smoser> jtv, that looks reasonable.
[03:02] <smoser> did you see my note that we will need packaging of that?
[03:02] <smoser> as right now maas-dhcp just has 1 file
[03:03] <roaksoax> smoser: i'll take care of that tomorrow morning :)
[03:03] <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.
[03:03] <smoser> jtv, so how are you going to configure $INTERFACES ?
[03:03] <jtv> /etc/default/maas-dhcp-server
[03:03] <jtv> Which also needs packaging.
[03:04] <smoser> jtv, no, my merge proposal had comment about it.
[03:04] <jtv> Oh
[03:04] <smoser> so you cant really do that
[03:04] <jtv> Didn't see that.
[03:04] <jtv> Why not?
[03:04] <smoser> hm..
[03:04] <smoser> so /etc/default/maas-dhcp-server is going to be a conf file
[03:04] <smoser> and if you edit it
[03:04] <smoser> and then the package upgrade
[03:05] <smoser> it will force a prompt
[03:05] <smoser> er... if the package'd file changes and there were local file changes.
[03:05] <roaksoax> smoser: we need to handle that automatically i'm afraid
[03:05] <jtv> Then... can we put it somewhere else?
[03:05] <smoser> roaksoax, right. so /etc/default/maas-dhcp-server is not the right place.
[03:05] <smoser> right.
[03:05] <jtv> /var/lib/maas/dhcp-interfaces?
[03:05] <smoser> for the things that you're configuring there, what i would suggest is some config not in /etc/
[03:05] <roaksoax> smoser: i already have an idea of how to handle that automatically
[03:05] <smoser> that maas managers
[03:06] <smoser> but what you *could* do is have /etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces'
[03:06] <smoser> or somethign like that.
[03:06] <smoser> but having maas edit that file i think is not right.
[03:07] <jtv> That's getting a little roundabout, given that all we want here is to set a variable.
[03:07] <jtv> Why not just...
[03:07] <jtv> if [ -f /var/lib/maas/dhcp-interfaces ]; then
[03:07] <smoser> you can do that. but i'd not bother with 'dhcp-interfaces'.
[03:07] <jtv>     INTERFACES=`cat /var/lib/maas/dhcp-interfaces`
[03:07] <jtv> etc?
[03:08] <smoser> but rather a shell sourceable file there.
[03:08] <smoser> and then you can set other things in it there also
[03:08] <smoser> rather than needing multiple settings potentially.
[03:08] <jtv> Well then we can do one better: just add a management command that prints out the interfaces.
[03:08] <smoser> thats what my suggestion above was
[03:08] <smoser> (/etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces')
[03:08] <jtv> Ah, then that'd be "maas" not "maas-shell," right?
[03:08] <smoser> sure. whatever it was.
[03:08] <smoser> or should be
[03:09] <smoser> but yes, ask maas what the value is
[03:09] <smoser> as it is the thing that knows
[03:09] <roaksoax> smoser: that's a cool idea
[03:09] <jtv> That's fine, yes.
[03:09] <smoser> anyway
[03:09] <smoser> bed time
[03:09] <smoser> good night.
[03:10] <jtv> nn
[03:12] <bigjools> so why is apache only listening on the one interface?
[03:13] <roaksoax> it is not, MAAS has as DEFAULT_MAAS_URL the IP of one interface
[03:13] <roaksoax> as a best effort attempt
[03:14] <roaksoax> to automatically determine what interface to be used
[03:14] <bigjools> ok
[03:14] <bigjools> to be used by what?
[03:14] <roaksoax> s/interface/address
[03:14] <roaksoax> to be used by MAAS as DEFAULT_MAAS_URL
[03:14] <roaksoax> in packaging that is
[03:14] <bigjools> I think we're confused about what it means
[03:15] <bigjools> as far  as the code is concerned, it's the internal-facing URL for the nodes to contact for API
[03:15] <roaksoax> bigjools: yep
[03:15] <roaksoax> bigjools: i know that :)
[03:15] <bigjools> ok :)
[03:16] <bigjools> so we need to prompt for it on installation
[03:16] <bigjools> it only does it on reconfigure
[03:16] <bigjools> or is that deliberate?
[03:16] <roaksoax> bigjools: that's deliberate. We cannot, should not prompt for it on installation
[03:16] <bigjools> in any case it picks the wrong ip/interface in the qa lab
[03:17] <bigjools> ok
[03:17] <roaksoax> bigjools: that's why we display a message saying that if it is the wroing address it should be changed
[03:17] <bigjools> gotcha
[03:17] <bigjools> it's coming back to me now
[03:17] <roaksoax> bigjools: if we always proimpt for it, it will break MAAS installation on the CD
[03:17] <roaksoax> s/on/from
[03:18] <bigjools> yeah
[03:19] <roaksoax> alright
[03:20]  * roaksoax is off to bed
[03:20] <roaksoax> goognight all
[03:21] <bigjools> nn
[08:45] <jam> jelmer, mgz: https://plus.google.com/hangouts/_/6b0c81dbfeb8a772657f16370d380d1e26c9a4d3?authuser=0&hl=en-GB
[12:32] <Daviey> roaksoax: not urgent today.. but can you explore using freeipmi-tools as a config option in maas upstream?
[12:34] <roaksoax> Daviey you mean instead of ipmitool?
[12:37] <Daviey> roaksoax: right
[13:09] <mgz> hm, I can't make after updating trunk because buildout is timing out trying to get repl
[13:11] <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
[13:12] <mgz> ah, need to edit the makefile
[13:34] <smoser> roaksoax, do you happen to know why maas uses 'python-twisted'  as a dependency
[13:34] <smoser> doku was asking me if that was necessary, versus a more fine grained list of what it actually uses.
[13:39] <roaksoax> smoser pserv and txlongpoll need it
[13:39] <smoser> but they dont need the blanket package
[13:40] <smoser> they need specific things it depends on
[13:40] <roaksoax> smoser why is that is it still uninstallable?
[13:41] <smoser> are you asking whether or not it is uninstallable? or asking *why* it is
[13:41] <smoser> i think doku probably fixed it, or if not is on it
[13:41] <smoser> and it will be fixed
[13:41] <smoser> but specifying a meta package when you dont need it is just wasteful
[13:41] <smoser> (not a big deal, just we probably get things we dont need)
[13:42] <roaksoax> python-twisted is a met package?
[13:55] <roaksoax> smoser smoser: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/required-packages/base
[13:57] <smoser> roaksoax, http://paste.ubuntu.com/1202679/
[13:57] <smoser> it sure looks as "mostly meta"
[13:58] <smoser> http://paste.ubuntu.com/1202680/
[13:58] <smoser> roaksoax, its low priority
[13:58] <smoser> but doku asked me
[13:58] <smoser> as we wouldn't have seen the uninstallable if we didn't depend on that package :)
[14:06] <smoser> rvba, around ?
[14:06] <smoser> {{kernel_params(arch="amd64") | kernel_command}}
[14:07] <smoser> what does that do ? in the templates
[14:07] <smoser> is it "call kernel_params *or* use kernel_command ?)
[14:07] <smoser> "
[15:23] <roaksoax> smoser: hold on
[15:24] <roaksoax> smoser: why was python-twisted uninstallable in the first place?
[15:24] <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
[15:25] <smoser> right.
[15:25] <smoser> you are correct, roaksoax . python-twisted should never have become uninstallable (that was a valid issue) and prevented maas from being installed.
[15:25] <smoser> but it just raised the question of "why were you depending on that meta package" rather than the specific packages you need
[15:26] <roaksoax> smoser: now, we need to find out what dependencies of python-twisted are needed by maas
[15:26] <roaksoax> allenap: ^^
[15:28] <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
[15:29] <roaksoax> smoser: as pserv runs a twisted daemon
[15:31]  * allenap looks
[15:32] <allenap> smoser, roaksoax: python-twisted-{core,web} is all I think for direct deps.
[15:37] <roaksoax> allenap: ok cool, i think we can update that then
[15:38] <allenap> Cool.
[16:03] <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()?
[16:04] <mgz> it's based on your C locale setting
[16:04] <allenap> mgz: I'm tempted to use sys.getfilesystemencoding() but I'm not sure that's a good idea.
[16:04] <allenap> mgz: en_GB.UTF-8
[16:04] <allenap> LC_ALL
[16:06] <mgz> okay, you probably are using bzrlib from a script but aren't calling `locale.setlocale(locale.LC_ALL, '')`
[16:07] <allenap> mgz: Ah ha, such are the runes needed. Thanks.
[16:34] <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
[16:34] <guimaluf> Sep 12 17:34:26 150.164.3.160 main-menu[582]: WARNING **: Configuring 'network-preseed' failed with error code 1
[16:34] <guimaluf> Sep 12 17:34:26 150.164.3.160 main-menu[582]: WARNING **: Menu item 'network-preseed' failed.
[16:41] <mgz> guimaluf: are you filing bugs about the issues you run into?
[16:41] <mgz> everyone: there's a really basic "what is maas" question on the openstack mailing list
[16:42] <mgz> I'd reply if I knew how to give a pithy answer.
[16:43] <guimaluf> mgz, no i'm not. I don't understand the cause of this issue. It happened out of nothing. :/
[16:45] <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
[16:46] <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
[16:47] <guimaluf> I know :/
[16:47] <guimaluf> I'm trying to get information about my issue, but I dont know where to go :/
[16:51] <mgz> so, hm, the launchpad MaaS page also suggests using askubuntu with the tag maas
[16:51] <mgz> but when you've got a bug, I'd just file against maas on launchpad
[18:06] <guimaluf> mgz, I found out the issue. the char 'é' inside comments on maas.pressed :/
[19:49] <melmoth> what does it mean when "juju deploy" on a maas server ends up with the new machine kept in "pending state" ?
[19:49] <melmoth> on a working install, as soon as i deploy something, i see a new machine id, with info about it
[19:50] <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
[20:22] <guimaluf> melmoth, have you check the ssh-keys? in my case I'd give up to use maas + juju + openstack.
[20:22] <guimaluf> cause of this. all my servers kept in pending state.
[20:22] <melmoth> yep, not the ssh key.. turned out zookeeper was having problem, did not investigate , we are on our way to a new bootstrap
[20:25] <guimaluf> melmoth, exactly! zookeeper problem!
[20:29] <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. :/
[20:34] <melmoth> guimaluf, http://pastebin.com/gtxGJgt3
[20:35] <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
[20:36] <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)
[20:36] <guimaluf> melmoth, partman can only handle with one disk. I want to make sd[b-z] also avaible
[20:36] <melmoth> havent try with several disk, my main problem was that i had only 1 anyway :)
[20:38] <guimaluf> I had, and partman dont deal with more then one disk. also none of my recipes had been aplied
[20:55] <melmoth> grumble same stuff again
[21:05] <melmoth> ahhh, note for later: dont put 127.0.0.1 for the maas server in the juju environment.yaml :)
[21:05] <melmoth> things seems better now