[06:37] <gmb> jtv: Where do we stand with the bootresources.yaml killage? I see a bunch of cards on the board but I assume that they’re just going to wither and die now.
[06:38] <jtv> gmb: the killage in itself is done.
[06:42] <gmb> Wewt
[06:43] <gmb> jtv: So we’re left with documentation and then UI stuff… What’s the word on the latter?
[06:44] <jtv> gmb: didn't we halt work on the latter?  The documentation is really just for making people aware of the change — the new way of doing things is already documented.
[06:44] <gmb> jtv: Yeah, we did, but I haven’t pored through all my email yet, so I wanted to check that we’re still halted :)
[07:18] <bigjools> jtv, gmb: ui is deeeed. long live the ui
[07:18] <gmb> bigjools: That’s *precisely* the conversation that I’m thinking could have happened somewhere :)
[07:19] <gmb> I’ve removed the UI cards anyway… we can always put ‘em back.
[07:26] <bigjools> gmb: yeah, well...
[07:27] <gmb> Ruh roh
[07:27] <bigjools> rvba: halp. django.
[07:27] <bigjools> self.filter(ip__gte=range_low, ip__lte=range_high)
[07:27] <bigjools> results in:
[07:27] <bigjools> TypeError: argument of type 'IPAddress' is not iterable
[07:27] <bigjools> dafuq
[07:28] <rvba> hum…
[07:28] <bigjools> ip is a GenericIPAddressField so I guess I need to do something
[07:28] <rvba> Weird that you're getting the error "is not iterable".
[07:29] <rvba> Nothing looks like it needs to be iterable in your query.
[07:29] <rvba> Do you have the full stacktrace?
[07:29] <bigjools> I am
[07:29] <bigjools> err I do
[07:29] <rvba> You're a stacktrace?
[07:30] <rvba> Please dial 911!
[07:30] <bigjools> http://paste.ubuntu.com/7571266/
[07:30] <bigjools> no such number
[07:30] <bigjools> :)
[07:32] <rvba> bigjools: looks like the operators for the GenericIPAddressField expect strings (not IPAddresses).
[07:32] <bigjools> !
[07:32] <bigjools> sigh
[07:32] <bigjools> thanks rvba
[07:32] <rvba> bigjools: They use "':' in value" to check if the value you give them is IPv6 or not.
[07:33] <bigjools> yeah
[07:33] <bigjools> rvba: I also have a dilemma
[07:33] <bigjools> rvba: my new model is called IPAddress which clashes nicely with the one in netaddr :(
[07:34] <rvba> Ah, right.
[07:34] <bigjools> gonna have to rename it I think, otherwise confusion will likely ensue
[07:34] <rvba> +1
[07:34] <bigjools> unless we prefix it everywhere
[07:35] <bigjools> suggestions for a new name?
[07:35]  * rvba thinks…
[07:35] <rvba> NodeIPAddress?
[07:36] <rvba> (Or is this going to be used to store non-node IPs as well?)
[07:44] <bigjools> yes
[07:45] <bigjools> I need to fix the column name called "type"... wasn't thinking too hard about that one
[07:45] <rvba> DeviceIPAddress then?
[07:48] <bigjools> rvba: StaticIPAddress
[07:48] <bigjools> since that's what it is
[07:48] <bigjools> and no more
[07:48] <bigjools> :)
[07:48] <rvba> Yeah, sounds good.
[07:48] <bigjools> they will be used for non-devices as well
[07:48] <bigjools> VIPs
[07:49]  * bigjools hax-rs
[07:52] <jtv> ManagedIPAddress?
[07:59] <bigjools> they're not all managed
[08:13] <Mosibi> Hi all.
[08:14] <Mosibi> Is this the right channel to ask for a MAAS problem? :: "No matching node is available" with juju deploy nova-compute
[08:22] <jtv> Mosibi: yes, this is the right channel — at least for the MAAS part.  It's possible that the origin of the problem is somewhere else, but let's have a look.
[08:22] <jtv> The error message means that a node was requested, but there was no node in the Available state that matched all of the constraints given in the request.
[08:38] <Mosibi> jtv: in tried several times, with and without setting constraints.
[08:39] <Mosibi> Could it be that there are constraints that i do not see?
[08:39] <jtv> Yes, that's quite possible.
[08:39] <Mosibi> okay...
[08:39] <Mosibi> Is there a possibility to show/extract that constraints?
[08:40] <Mosibi> Setting MAAS in debug mode did not show me anyhting more i allready knew.
[08:52] <rbasak> Mosibi: I've seen constraints embedded in the HTTP GET URI inside one of the log files in /var/log/maas/
[08:52] <rbasak> I'm not sure if that's still the case but it maybe that will help?
[08:55] <rvba> bigjools: happy to have a pre-imp about the DHCP work now if you're available.
[08:55] <bigjools> rvba: bien sur
[08:55] <jtv> Mosibi, rbasak: Yes — some clients will pass those parameters in that way — I think those would go in /var/log/apache2/access.log though.
[08:55] <bigjools> rvba: I'll head back to same hangout
[08:55] <rvba> okay
[08:56] <rvba> bigjools: s/sur/sûr/ (sur ~= dessus, sûr = certain)
[08:58] <jtv> Weird place for a vestigial ‘s’...
[09:00] <gmb> jtv, rvba, bigjools, allenap: A review, if you please: https://code.launchpad.net/~gmb/maas/update-changelog-bootresources.yaml/+merge/221678
[09:00] <jtv> Coming.
[09:00] <gmb> Had to invent the 1.5.2 release for the sake of the update…
[09:01] <Mosibi> rbasak and jtv: thx will have a look at the httpd logs
[09:12] <Mosibi> Sadly i could not find any contraints in the httpd log files.
[09:13] <Mosibi> I noticed when i force a tag on one off my 'ready' machines in MAAS and after that, do a juju deploy with --contraints tag=mytag, the deployment starts
[09:15] <rbasak> Mosibi: did you set constraints when you bootstrapped the environment?
[09:15] <rbasak> IIRC, that sets default constraints. There is a command to change the default.
[09:18] <Mosibi> rbasak: nope, i did not set any constraints when i bootstrapped the environment.
[09:19] <Mosibi> let me explain what i am trying/doing :)
[09:20] <Mosibi> i am building a demo openstack environment with juju and allready deployed the openstack components with juju
[09:21] <Mosibi> So i have, keystone, cloud-controller, quantum-gateway etc...
[09:21] <Mosibi> Thus i have a working MAAS/Juju env.
[09:22] <Mosibi> Now i want to deploy a nova-compute host and i have 4 (virtual :: KVM) compute nodes available in MAAS.
[09:22] <Mosibi> And that's te troubling part..
[09:22] <Mosibi> +h somewhere :)
[09:24] <Mosibi> To me it looks like the nova-compute charm should have set some constraints (i need x mem and minimaal x CPU's), but i can not find any of that in the charm itself.
[09:24] <jtv> Maybe even a constraint to ensure that you get a physical machine.  I guess that might explain what's happening — if we can find it.
[09:25] <rbasak> Mosibi: you would do that in your deployment yourself, or via your bundle I think. It sounds to me that MAAS is doing exactly the right thing for you, and that you have a juju question if anything. Try #juju for more expertise maybe?
[09:25] <Mosibi> Since MAAS is returning the 'No matching node is available', i would love to see the list of contraint MAAS is working with.
[09:26] <jtv> No reason to show those in the error message, really.  I'll file a bug about that.
[09:26] <jtv> No reason *not* to, I mean!
[09:26] <Mosibi> rbasak: indeed, it looks like a juju problem, but i would like a more 'verbose' notice from MAAS
[09:26] <Mosibi> jtv: :)
[09:27] <Mosibi> jtv: thx!
[09:27] <Mosibi> rbasak: also thx for your insights
[09:27] <Mosibi> I'll switch to #juju :)
[09:28] <jtv> Ah, we already have bug 1274085 — but the counter-argument is that MAAS returns a raw API error, and maybe it's up to Juju to show what it was trying to do (at a higher level of abstraction).
[09:29] <Mosibi> jtv: that's a 'he, but we aren
[09:29] <Mosibi> 't doing anything wrong'
[09:30] <Mosibi> Since MAAS is receiving the call, more verbosility would be welcome and more important: it would lower the support calls in #maas :)
[09:30] <jtv> Yes, I agree our message could be clearer.  I can probably just fix the message.
[09:31] <Mosibi> jtv++;
[09:31] <Mosibi> :)
[09:31] <jtv> It may be that Juju can do a better job, but that's not in itself an argument against not doing one ourselves.
[09:31] <Mosibi> idd
[10:09] <gmb> allenap, jtv, rvba: anyone free for a preimp about https://bugs.launchpad.net/maas/+bug/1312844?
[10:15] <jtv> gmb: will be in a minute
[10:15] <gmb> jtv: Okay, call me when you’re ready.
[10:16] <jtv> Will do.
[10:18] <jtv> gmb: rinnggg
[10:18] <gmb> Total lack of notifications
[10:18] <jtv> Maybe I invited your wrong persona.
[10:34] <bigjools> there's JS lint... how did that appear I wonder
[10:41] <jtv> There seems to be some weirdness where sometimes lint just doesn't get reported.
[10:42] <bigjools> rvba: https://code.launchpad.net/~julian-edwards/maas/allocate-static-ip/+merge/221702
[10:42] <bigjools> and now I shall EOD
[10:42] <bigjools> jtv: do you have an IRC notification on the word "lint" ? :)
[10:43] <jtv> Hey, the NSA's got to be good for _something_...
[10:44] <jtv> It may be version skew, or something at a low level limiting itself to revision-controlled files, or something.
[11:01] <jtv> allenap: session-level locks... but the locking code opens and closes a dedicated cursor for each locking command.  Do we know that those cursors are on the same session..?
[11:08] <allenap> jtv: That’s up to Django ;)
[11:09] <allenap> jtv: Maybe it should keep that cursor around?
[11:09] <jtv> Then that would explain the problem...
[11:15] <allenap> jtv: If the session is going away, then that’s Django’s responsibility I think, though it might just be going away because of garbage collection, in which case holding the cursor should prevent that.
[11:41] <allenap> jtv: Do you think it’s worth trying to validate that, or should we just go straight to keeping a reference to the cursor around?
[12:02] <jtv> allenap: it really ought to be the same session that's performing the locked operation.
[12:05] <rvba> jtv: Although Julian's solution is probably good as a first step, I seem to remember you had a better idea, to allocate new IP addresses, than select one in the allowed range different from the pool of existing allocated IP addresses.  This solution is a bit racy, obviously.
[12:23] <jtv> rvba: not sure I fully undestand you, but that sounds like how we thought our existing scheme would work — which might work with a different dhcpd.
[12:23] <rvba> jtv: this is about the code Julian mentioned this morning.
[12:24] <rvba> The code to allocate a new IP address.
[12:24] <jtv> Oh, for picking a free address.
[12:24] <rvba> Yeah.
[12:24] <jtv> Right.  The idea there was to cache a pool of available addresses.
[12:25] <rvba> cache?
[12:25] <rvba> This means like a weird way to second-guess the DB…
[12:26] <jtv> That's pretty much what caches are.  The database is the source of truth, but a cache can help find efficient "guesses."
[12:26] <rvba> Right.  Well, I guess that's probably something we can do as a second step.
[12:26] <rvba> Looks like an optimization.
[12:26] <jtv> Exactly.  It's optimisation.
[12:52] <gmb> allenap: Is there “nice” way to untangle where a circular import is creeping in? I see errors that are utterly unrelated to where I’m working at the moment and it’s highly frustrating to have to comment stuff out, especially in a big file.
[12:57] <gmb> rvba, jtv: That question was for you too; I jsut wanted to engage the Gavinator…
[12:58] <rvba> gmb: the only solution I know is the local import.
[12:58] <gmb> rvba: Yeah, I know the solution, I’m trying to find a nice way to identify the actual problem imports.
[12:59] <rvba> Oh, I see.
[12:59] <gmb> So I’m working on maasserver.forms and I see things like:
[12:59] <gmb>   File "/home/graham/workspace/maas-work/maas/src/maasserver/views/clusters.py", line 45, in <module>
[12:59] <gmb>     from maasserver.forms import (
[12:59] <gmb> ImportError: cannot import name NodeGroupEdit
[12:59] <gmb> I know that maasserver.forms has the problem but it has 80 lines of imports :)
[12:59] <gmb> And I don’t know which one to kill with fire.
[12:59] <rvba> In Django, it's usually the models that are the problem.
[13:00] <gmb> Well, that helps a bit… It at least gives me a place to start, which is better than my current scattergun approach.
[14:30] <allenap> jtv: I have discovered that Django closes the connection when it pleases, so DatabaseLock.__enter__() and .__exit__() can run in entirely different sessions.
[14:30] <allenap> jtv: It explicitly closes it too, so hanging onto a reference does no good.
[14:32] <allenap> I feel that Django owes it to us to remove itself from the MAAS codebase.
[14:45] <jtv> allenap: it can't reasonably close a connection while it's in a transaction though, so if we can get a hold of our "regular" DB session, we'll be alright.
[15:02] <allenap> jtv: Ensuring that the _session_ lock is taken within a _transaction_ seems to satisfy Django.
[15:02] <jtv> allenap: satisfy in what way?
[15:04] <allenap> jtv: It keeps the connection open.
[15:04] <allenap> And thus the session.
[15:04] <jtv> Is that a promise?  Or could there be some pool with its own eviction policies?
[15:05] <allenap> jtv: I’ve added a check to DatabaseLock.__exit__() to ensure that it’s actually released a lock that it held. That ought to keep us on our toes.
[15:06] <jtv> Thanks.  At least it'll give us a more precise failure.
[16:03] <allenap> jtv: If you’re around, would you mind having a look at https://code.launchpad.net/~allenap/maas/database-locks-revisited/+merge/221762?
[16:03] <jtv> Not at all.
[16:03] <allenap> Thanks :)
[16:09] <jtv> allenap: done
[16:15] <allenap> Tip top, thanks jtv. I hope this will plug the problem.
[16:17] <jtv> As we say in Dutch, I'll help you hope.
[16:20] <allenap> Heh, I like that.
[16:39] <blake_r> allenap: could you do a review of this review!
[16:40] <blake_r> allenap: https://code.launchpad.net/~blake-rouse/maas/powernv-support/+merge/220840
[16:40] <allenap> blake_r: Sure. OTP right now, I’ll do it later. Is that okay?
[16:41] <blake_r> allenap: i think roaksoax was wanting it really soon, for sru
[16:42] <blake_r> allenap: anyone else around maybe?
[16:42] <allenap> jtv, gmb: Either of you free for urgent review? ^
[16:42] <jtv> I can take it.
[16:42] <blake_r> jtv: thanks
[16:42] <jtv> Is it Blake's?
[16:42] <jtv> That answers that.  :)
[16:42] <blake_r> jtv: yeah
[16:43] <blake_r> jtv: so don't be to harsh!
[16:43] <blake_r> jtv: also jhobbs already did a review on it
[16:43] <jtv> I'll be harsh if it's huge!
[16:44] <blake_r> jtv: <800
[16:44] <blake_r> jtv: like requested!
[16:44] <jtv> Took me a while that wasn't an emoticon... "obese KKK member" or something.
[16:45] <jtv> *to figure out
[16:45] <blake_r> Haha!
[16:51] <jtv> blake_r: Jason is right about the factory convention.  We try not to be fanatical about it, but it does help answer the question "where from?"
[16:51] <jtv> Ahem.  That's a bit non-ab-ovo.  I mean: we do usually prefer "make_foo" factory functions over "get_foo" ones.
[16:51] <jtv> Now all you need to do is read my messages in the wrong order.  :)
[16:52] <blake_r> jtv: no make_mac_address in pserv
[16:53] <blake_r> jtv: did want to add to the line count, :)
[16:53] <blake_r> jtv: didn't*
[16:53] <jtv> If it's for testing, there's one in maastesting.factory.  But it follows an aberrant convention: getRandomMACAddress.  :(
[16:53] <blake_r> jtv: yep, the one i used!
[16:56] <jtv> On another arbitrary note, compiling regexes probably isn't useful in many situations.  IIRC there's transparent caching for those million-in-a-row cases.
[16:59] <jtv> Not that I'm against it, but if it gets in the way, don't let your conscience stop you.
[17:16] <rvba> allenap: looks like your recent modification broke the build.
[17:16] <rvba> allenap: d-jenkins.ubuntu-ci:8080/view/MAAS/job/utopic-adt-maas/54/
[17:16] <rvba> allenap: paste.ubuntu.com/7574376/
[18:09] <allenap> rvba: Hey, that’s great news! Really :)
[18:10] <allenap> rvba: I’ll investigate this evening.
[18:10] <allenap> rvba: Is that CI of trunk?