[07:38] <bigjools> jtv, rvba: did either of you have a chance to look at my schema changes?
[07:38] <jtv> Not yet, not yet...
[07:40] <rvba> bigjools: not yet :/
[07:40] <bigjools> no worries, I need allenap to look too anyway :)
[07:40] <bigjools> I made a load of changes to the design doc
[07:56] <jtv> There goes the lander again!  Something is wrong.
[07:56] <jtv> Notice how many rabbit brokers get reported when this happens?  I wonder if we're leaking any.
[08:16] <rvba> jtv: looks like you got a different error this time!  FAIL: maasserver.tests.test_js.YUIUnitTestsLocal.test_YUI3_unit_tests
[08:17] <jtv> Gah!  Three in one branch!
[08:17] <rvba> I suspect there is something wrong with the lander's machine.
[08:17] <jtv> Yes, that last one sounds like it might be related to memory leaks also.
[08:17] <jtv> After all, browser tests are normally the most taxing for the system.
[08:18] <rvba> Yep.
[09:27] <rvba> jtv: Branch landed \o/
[09:29] <jtv> rvba: thanks — I hope the G figures it out because this is intowewwabwe
[09:30] <jtv> I shouldn't have named the branch after the Punic wars — those took several attempts too.
[09:44] <AskUbuntu> Unable to access MAAS nodes | http://askubuntu.com/q/473350
[13:15] <libsysguy> Hi all. I was wondering if someone could help me troubleshoot.  I have a fresh maas install and I am getting a metric *ton* of oops logs when pxe tries to run on the nodes.  I generated an sos report and put it here: https://drive.google.com/file/d/0BwO0l99GoKIxeUFxTHgxaGR0Sk0/edit?usp=sharing
[13:15] <libsysguy> but mostly the oops logs just repeat Failure: twisted.internet.error.TimeoutError: User timeout caused connection failure.
[13:28] <libsysguy> actually guys, I just got it.  Thanks anyway
[13:43] <ophuk> is it possible to have the MAAS management interface be different than the PXE/Provision interface? Say I want to control the box through the web interface through <IP_ADDRESS> and I want the cluster to work through a second ethernet interface with an ip of <IP_ADDRESS>. Is this possible?
[13:45] <jtv> ophuk: if you're talking about power management through e.g. IPMI, then yes, it's a matter of choosing the node's "power address."
[13:45] <jtv> That's for turning the node on or off.  Is that the type of control you have in mind?
[13:46] <jtv> AMT should be able to do the same, from what I hear, although by default it simply sits on the same interface.
[13:46] <ophuk> jtv: not really. I have one box with two network interfaces, one public and one private. I want to be able to access the web interface through the public interface and I want the private interface there for the PXE, DHCP, and DNS for the cluster
[13:47] <jtv> Oh, we'er talking about the network interfaces _on the server_?
[13:47] <ophuk> jtv: yes, sorry
[13:47] <jtv> Sorry, I thought you meant the network interfaces on the node.
[13:47] <jtv> Yes, those are meant to be different things (which can of course be the same NIC if you want).
[13:48] <ophuk> jtv: no worries. I feel like it should be possible but my googling is coming up with anything. It could be because I'm looking for the wrong thing
[13:48] <jtv> I'll have to refresh my memory, but at a guess I would say that Apache (which runs the region controller) listens on all interfaces.
[13:49] <rvba> Yes, Apache listens on all interfaces.
[13:49] <jtv> In addition to that, there's a setting (again, rusty memory) for the URL which nodes should use when talking to the region controller.
[13:49] <rvba> ophuk: this should work out of the box.
[13:50] <jtv> The installation does have a question for "which interface on the region controller faces the nodes," but I don't think you typically get to see that.
[13:50] <jtv> I'll shut up for a bit and refresh that memory.
[13:50] <ophuk> jtv: ok, so if I do sudo dpkg-reconfigure maas-cluster-controller and set that to the public IP, this allows me to view the web interface from the public IP. But how do I tell it to use the other interface for PXE,
[13:51] <jtv> It's sort of the other way around.
[13:51] <rvba> ophuk: you want to use the private IP for that.
[13:51] <jtv> What rvba said.
[13:52] <jtv> The UI is on any of the server's addresses; what needs to be known is which address is reachable for the nodes.
[13:52] <jtv> That's going to be the "private" address in your case.
[13:52] <ophuk> rvba: ok - so that should be set to my internal IP. That's what I had originally but going to the public interface through a web browser wouldn't bring up the MAAS web ui. I was getting a server 500 error
[13:52] <jtv> That sounds like you _were_ reaching it, but something else went wrong.
[13:52] <rvba> What jtv said.
[13:53] <jtv> Gotta love symmetry.
[13:53] <ophuk> jtv: yeah apache was working - my public IP is <IP_ADDRESS> but going to <IP_ADDRESS>/MAAS/ wasn't. I just attributed that to the wrong interface
[13:53] <ophuk> great minds think alike:)
[13:53] <jtv> Thank you... :)
[13:54] <jtv> Shall we have a look at the original problem then, and see if that solves the rest?
[13:54] <jtv> First place to look is the Apache error log.
[13:54] <ophuk> jtv: yeah. I did the the reconfigure maas back to the internal IP
[13:57] <ophuk> jtv: one sec - uploading a pastebin
[13:57] <ophuk> jtv: rvba here you guys go - this is the error log, http://paste.ubuntu.com/7536756/
[13:57] <ophuk> I moved the original and cleared it out and tried to reconnect. That is what I got
[13:58] <rvba> Looks like the connection to RabbitMQ timed out.
[13:59] <jtv> Innnteresting.
[14:00] <ophuk> also as I side not I'm not terribly attached to this install, if you feel like something might of gotten messed up during the install I can do it again - it just takes forever to reimport the isos
[14:01] <jtv> Well that can be solved by moving /var/lib/maas/boot-resources/cache out of the way somewhere, and moving it back into the new install.  :)
[14:02] <ophuk> jtv: well that is good to hear:)
[14:05] <jtv> ophuk: rabbit does tend to get upset when its IP address changes.  I don't know if that's related.
[14:06] <jtv> (In this case that'd be a little silly since from the sound of it, its communication will be entirely local to the machine.)
[14:06] <ophuk> jtv: it is quite possible because it originally pulled an IP from DHCP in the 172 range and then I had to change it to the public and private IP's. I don't remember an option during the install for setting up both nics
[14:07] <jtv> Ah!
[14:07] <jtv> Then I think that explains it.  I've had some luck in the past just editing the rabbitmq config myself, but that wasa before doing much actual work with the setup.
[14:08] <ophuk> jtv: hmm...ok. Where is this config file?
[14:10] <jtv> Looking for it...  Curses, I've done this before.
[14:11] <rvba> jtv: I'm not sure where the piece of documentation that I'm writing belongs… The best place is probably the online documentation but you've documented the bootsource/bootsourceselection stuff in the import script's manpage so I'll have to redo/copy that part to add the relevant context… that's a bit suboptimal.
[14:11] <ophuk> jtv: /etc/rabbitmq/rabbitmq.config ? I don't have that file
[14:11] <ophuk> o.O
[14:12] <jtv> ophuk: same here, and I could have sworn I did just a few months back.
[14:13] <jtv> This may just be a rabbit change.  Change is great, but one wishes the rest of the world would ask one's permission before making any.  :)
[14:13] <ophuk> jtv: lol - is it possible to do this during install, i.e. configure a static IP on both nics?
[14:13] <jtv> rvba: the man page should ideally cover only the command-line script, not the API/UI/CLI-triggered "proper" import.
[14:14] <rvba> jtv: agreed.  What's suboptimal is that I'll have to copy part of the documentation from the script to the online doc.
[14:15] <jtv> ophuk: I seem to remember some confusion when reconfiguring afterwards, along the lines of "is this a URL or just an IP address?"  What I did in the past was just grep /etc for my IP address, and see where the fixes need to be.
[14:15] <jtv> rvba: I don't suppose you can move it, and just make the script refer to the online version?
[14:16] <rvba> jtv: I'd like to keep the description of the config file's format in the manpage.
[14:17] <jtv> Ah, that part..  I agree, though it's been a bit of a pain tracking changes.
[14:47] <newell> I am new to maas development.  I am trying to make it so the maascli (i.e. I will need to make API changes) that allow us to do:  maas <profile> node read <hostname | system_id>
[14:48] <newell> so we  would be adding it so that we can read a node via the system_id (current) or hostname (new)
[14:48] <newell> Curious where in the API this change would need to occur
[14:49] <roaksoax> jtv: ^^
[14:49] <roaksoax> rvba: ^^
[14:50]  * newell is happy to be doing it in the right channel finally
[14:50] <jtv> roaksoax: newell & I have been conversing about this, we just moved to a new channel.  :)
[14:50] <rvba> heh
[14:50] <roaksoax> jtv: ah ok :)
[14:51] <jtv> newell: I think what you'd do at the moment is: maas <profile> nodes list hostname=<hostname>
[14:51] <jtv> There must be some convenient command-line tool for manipulating/querying JSON...
[14:51] <roaksoax> jtv: so, what if we would like to change anything that needs system_id to also be possible to specify hostname
[14:52] <roaksoax> jtv: for example, we have been experiencing difficulty when adding/removing tags
[14:52] <jtv> roaksoax: then I'd do some broader planning first, just because it's a technical departure.
[14:52] <roaksoax> jtv: because every time we want to do it, we have to first obtain the system_id, so we would like to move to a world where I can just do API operations specifying a node's hostname, as it is unique
[14:53] <roaksoax> jtv: so, I'd definitely say that we should support both, system_id|hostname
[14:53] <jtv> First though, doesn't the Tag API let you do this?
[14:53] <jtv> Because this is a relationship between Tag and Node, and Node is the side where the scale is.
[14:54] <jtv> So maybe it'd make the most sense to say something like "add tag X to the nodes I specify as parameters."
[14:54] <jtv> At that point, there's no technical departure and you no longer need to loop over all nodes for mass updates.
[14:55] <roaksoax> jtv: so what do you think is more appropriate? Being able to do *any* node related operation (that currently needs system_id) with the hostname of the node instead (or alternatively) of using system_id? or for 1 or 2 methods being able to specify hostnames?
[14:55] <roaksoax> jtv: it is my perspective that management via the CLI would be highly improved by being able to specify a node's hostname instead of a system_id
[14:56] <roaksoax> jtv: because in the latter case, we are just doing a "work around"
[14:56] <jtv> I don't think so.  It's just the more scalable way to phrase the request.
[14:56] <roaksoax> jtv: obviously, there will be places where we could experience issues, such as when we are to update a node's details
[14:57] <roaksoax> jtv: right, but right now, for any operation we want to make, we have to do the following: 1. obtain list of nodes. 2. grep for X node. 3. get its system_id. 4. perform operation
[14:57] <roaksoax> jtv: usability wise, that is *very* painful
[14:57] <jtv> Since hostnames really only make sense while a node is allocated, I guess another factor that comes into this is under which circumstances the operation makes sense on a given node.
[14:58] <jtv> I don't think you understand what I said.
[14:58] <roaksoax> jtv: they don't really only make sense when node is allocated. Hostnames make sense anytime because it is a nice way to identify a node, That's why DNS was created
[14:59] <jtv> Given that you can tag a bunch of nodes which you pass as parameters, there's nothing against passing them _as hostnames_.
[15:00] <roaksoax> jtv: right I got your point, however, what I'm trying to explain is that does solve the problem IMHO
[15:00] <roaksoax> jtv: right now, if I want to update a node, I have to do 1. 2. 3. and 4. above
[15:00] <roaksoax> if I want to update a tag, I have to do the same thing
[15:00] <jtv> No you don't, is my point.
[15:00] <roaksoax> there's many operations that require system_id to be passed
[15:01] <roaksoax> maas maas tag update-nodes my_tag add="<system_id>"
[15:01] <jtv> What I'm saying is this needs some more careful thought since it's a technical departure.
[15:01] <ophuk> how come when you're installing maas from a live CD do you don't have an option to set a static IP when creating a new MAAS server?
[15:01] <roaksoax> for me to do that, i need to 1. obtain list of nodes. 2. grep for X node. 3. get its system_id. 4.perform oeperaiton
[15:01] <jtv> And you're just pushing for the solution you have in mind, which may or may not be fine, but we can end up going down a blind alley if we run with the first suggestion.
[15:01] <roaksoax> jtv: so yes, in this particular case being able to specify hostname instead of system_id does make sense
[15:02] <jtv> roaksoax: not quite what you need to do.  You can ask explicitly for just the node with the given hostname.
[15:03] <roaksoax> jtv: right, but you are still asking for a node with a given hostname
[15:03] <roaksoax> jtv: 1. ask for a node with a given hostname. 2. obtain its system_id. 3. perform any other operation I need
[15:03] <roaksoax> jtv: why can't we just go to 3 directly by using its hostname instead of obtaining a system_id
[15:03] <jtv> Think of it as OO if you prefer: you ask for the node, and you get its URL.
[15:04] <roaksoax> jtv: right, that might be the case, but the CLI is a usability thing
[15:04] <jtv> I see that you want to cut out that step, and I'm trying to help, but we do need to discuss the broader problem without pushing for the original suggestion.
[15:05] <roaksoax> jtv: CLI as to make admin's life easier, not more complicated
[15:05] <jtv> I'm trying to help you, but pushing and pushing instead of going through the design process makes that harder, not easier.
[15:06] <roaksoax> jtv: I'm not pushing, I'm trying to figure out what is needed to make this happen (which is going through the design process)
[15:06] <jtv> And I'm sorry for seemingly distracting you from your path to that solution, really I am.  But experience taught us that it's something we have to do.
[15:07] <jtv> So the problem we have on the table is "I want it to be simpler to write changes to a node."  Right?
[15:13] <newell> roaksoax, ^^
[15:14] <jtv> Not just, "I want it to be easier to manipulate tags on a node."
[15:17] <roaksoax> jtv: for every single node related operation (other than updating hostname), we need to obtain the system_id. That is affecting usability, so basically, I'd say that every single operation that currently requires a node's system_id, should accept the hostname (other than when updating a node's hostname of course)
[15:19] <jtv> That's much better, thanks.
[15:36] <jtv> roaksoax: the original architectural guideline for the API, which we've been lax about, was to focus on batch-oriented operations for scalability.  Unfortunately of course scale and friendliness are not good friends, and we do very much want more friendliness in the CLI.
[15:38] <jtv> Some ideas for things we might want to look into in exploring your suggestion:
[15:39] <jtv> 1. How would hostnames show up in URLs?  System IDs are "safe ASCII," hostnames have their own restrictions (including hopefully unicode at some point!)
[15:39] <jtv> I think it's probably OK of course, just noting to check.
[15:40] <jtv> 2. Is there any chance of ambiguity?
[15:40] <jtv> Need to check whether a hostname can also be a well-formed system ID or vice versa.
[15:47] <roaksoax> jtv: agreed.
[15:47] <roaksoax> newell: did you join the maas-devel ML?
[15:47] <roaksoax> newell: can you raise some discuss about it?
[15:48] <roaksoax> jtv: then we would be able to estimate work effort and we can decide from there if this is somethign we can fit this cycle
[15:48] <newell> hmm not sure let me check
[15:48] <newell> roaksoax, you want me to send out an email to the list summarizing the conversation here that you and jtv have mostly had?
[15:52] <jtv> newell, roaksoax: it's currently possible for the same identifier to be one node's system ID and another node's hostname... that's probably something we could just forbid if we have to.  It's a UUID, so not a lot of risk.
[15:53] <roaksoax> newell: yeah an email talking about the possibility of allowing the API use <system_id | hostname> for all operations that currently require the system_id, and some background, and the ideas raised by jtv
[15:53] <jtv> (Unless somebody tries to rename nodes as a way of getting one to take over another's role or something)
[15:54] <newell> roaksoax, okay will do
[15:54] <jtv> Thanks.  Mailing list is good for this.
[15:54] <roaksoax> newell: thank you
[15:54] <newell> npo
[15:54] <roaksoax> jtv: and agreed, yes we need t consider various variables
[15:54] <newell> np*
[15:54] <jtv> Yeah.  Sorry for being difficult about it — we've had some really bad experiences going in to quickly with a solution, and had to force ourselves to do this.
[15:55] <jtv> It always feels a bit like sabotage...
[15:55] <jtv> But I'm glad that you're looking into user-friendliness improvements to the CLI!
[15:56] <jtv> We're OK on the hostname-in-URL issue, I think.  Once we start supporting full unicode I guess we'll have to percent-encode — no drama.
[15:59] <roaksoax> jtv: oh not at all, please rest assured that me bringing this up was to simply raise some discussion about the issue to reach a solution that would benefit all of us and our users
[17:11] <ophuk> I've got a node in a ready state but I can't click on start node - there is a blue message up top stating an adequately configured DHCP server can boot this node. I did the DHCP/DNS server stuff through the web UI, is there something I'm missing?
[17:16] <roaksoax> ophuk: did you add the SSH key for the user?
[17:17] <ophuk> roaksoax: this part, maas-cli login maas http://<IP_ADDRESS>/MAAS/api/1.0 and then the key from the web UI? Yes
[17:18] <roaksoax> ophuk: nope
[17:18] <roaksoax> ophuk: go to the webui
[17:18] <roaksoax> and go to the User Settings
[17:18] <roaksoax> and add a SSH Key (public key)
[17:18] <roaksoax> so you can ssh into the nodes after deployment
[17:23] <ophuk> roaksoax: ok, recommissioning and seeing what happens.
[17:36] <jtv> ophuk: there should be a hover message on the greyed-out button saying why you can't use it.
[17:37] <ophuk> jtv: ok, I'll check it
[17:40] <ophuk> jtv: it is working now
[17:40] <ophuk> roaksoax: that fixed it i believe...thanks:)
[18:36] <AskUbuntu> Tips for troubleshooting IPMI in MAAS 1.6 | http://askubuntu.com/q/473587
[19:32] <jfarschman> Hello... I'm trying to work with preseed_master by making a copy "amd64_generic_trusty"  but when I do this I get an error on line 70
[19:33] <jfarschman> name 'self' is not defined at line 70 column 3 in file /etc/maas/preseeds/amd64_generic_trusty
[19:33] <jfarschman> This is something easy :)
[19:36] <jfarschman> --- was reading about user-provided preseeds here http://maas.ubuntu.com/docs/development/preseeds.html
[20:27] <jfarschman> Figured it out. Apparently inheritance is odd.
[21:43] <jfarschman> okay something so basic, anyone can help
[21:44] <jfarschman> After I have a node allocated and built in MaaS how to I force a rebuild?
[21:44] <jfarschman> want the OS loaded again to test my preseed scripting.
[21:45] <blake_r_> jfarschman: stop and start the node
[21:45] <jfarschman> blake_r_: but how do I put it in a state where it knows to rebuild?
[21:46] <jfarschman> it should not rebuild on every reboot.
[21:46] <blake_r_> jfarschman: what do you mean rebuild?
[21:46] <jfarschman> reinstall the OS, invoking the preseed modifications I just made
[21:46] <blake_r_> jfarschman: when you stop a node, it is considered no longer in use
[21:46] <blake_r_> jfarschman: when you start it again it will be re-installed
[21:46] <jfarschman> I did an install yesterday that was generic... now I need to do an install that adds puppet
[21:46] <jfarschman> oh... hahaha.
[21:47] <blake_r_> jfarschman: start means turn on, and give me a clean installed system
[21:47] <designated> if it still exists in maas, the os will not be reloaded.
[21:47] <blake_r_> jfarschman: so be careful with that stop button, :)
[21:48] <designated> otherwise a power failure would cause every server to reload OS
[21:48] <blake_r_> designated: if the node is allocated and you click stop it will power off, and become unallocated
[21:48] <blake_r_> designated: next time you click start it will allocate to you and install
[21:48] <jfarschman> yea... I just assumed it was going to use IPMI and shut it down for me.  but I like this method.
[21:48] <blake_r_> designated: if you restart the node, from the machine it will reboot, and will not reinstall
[21:49] <designated> blake_r_, correct, it must be issued from within maas.  simply power cycling the node will not kick off a new OS load.
[21:49] <blake_r_> jfarschman: yes it will use IPMI and power off the node
[21:50] <blake_r_> designated: power cycling? if you use ipmi directly or un-plug it and back in, it will nto re-install
[21:50] <blake_r_> designated: if you use maas to control the node, it will re-install
[21:51] <blake_r_> designated: so in a data center and the power goes off, they will all restart to where they were before power cycle
[21:51] <jfarschman> blake_r_: that language, "stop selected nodes" is a little deceptive.  Perhaps deprovision
[21:51] <designated> blake_r_, we're saying to same thing.  I was trying to make sure jfarschman understood that maas had to be used, simply power cycling the node would not initiate OS load.
[21:52] <designated> jfarschman, exactly
[21:53] <blake_r_> jfarschman: https://bugs.launchpad.net/maas/+bug/1311224
[21:54] <designated> the maas documentation isn't entirely clear on a lot of things, like advanced networking for example.  How do you bond interfaces for LACP and use VLAN tagging?
[21:54] <blake_r_> designated: good question?
[21:54] <blake_r_> designated: idk, :)
[21:54] <blake_r_> designated: never done that!
[21:55] <designated> some things in the documentation are outright wrong.
[21:55] <blake_r_> designated: are you using the correct version of the documentation, for your version
[21:55] <designated> blake_r_, yes
[21:55] <blake_r_> designated: please create a bug, if its wrong
[21:56] <designated> I've been hesitant because this is the most active I have ever seen this IRC channel.  doesn't seem like a very active community, figured it was a waste of time.
[21:56] <blake_r_> designated: we are very active, on launchpad
[21:57] <designated> blake_r_, ahh i see
[21:57] <blake_r_> designated: will try to be more on here
[21:59] <designated> having access to more advanced networking features, like LAGG and VLAN tagging, as well as the ability to adjust disk partitions without having to manually write a preseed are essential to success for a project like this, especially if you plan on using juju to deploy software.  juju for example works great when deploying to a cloud but when deploying to bare metal, you need access to hardware, like multiple NICS or bonded and trunked inte
[21:59] <designated> rfaces.
[22:00] <blake_r_> designated: I know that VLAN tagging is supported, just don't know to what extent and the ability of MAAS
[22:00] <designated> i tried deploying openstack on juju and maas, it was a nightmare because of limited network support and disk partitioning options.  who deploys openstack on hardware with a single interface?
[22:01] <blake_r_> designated: juju neutron uses a second nic interface
[22:01] <blake_r_> designated: adjust for partition would be hard, who would you handle different size hard drives?
[22:01] <designated> blake_r_, if the community is truly active, I would definitely be interested in getting involved.  I just don't want to adopt something that isn't actively developed and wind up with problem after problem...
[22:02] <blake_r_> designated: it is actively developed
[22:02] <blake_r_> designated: and a key project for canonical
[22:03] <designated> i did write a bash script to solve the problem of mac to name nic mapping inconsistencies across a pool of servers that gets pulled in during preseed, that was a huge issue i was having when trying to use juju with maas
[22:03] <designated> blake_r_, i believe it is, it's just knowing how to get ahold of the developers to interact with them :)
[22:03] <jfarschman> One more.... My provisioning of Trusty stops and [!!] Partition Disks and asks me to make a choice.  This is normal?
[22:03] <blake_r_> jfarschman: no it should not ask you any questions
[22:04] <blake_r_> jfarschman: you must have not answered all of the questions required in your preseed
[22:04] <designated> jfarschman, i would think if the disk partitioning portion of the preseed was complete, it wouldn't do that.  I've never had that issue.
[22:04] <blake_r_> designated: talking to one now!
[22:04] <jfarschman> It did on the first install with the default preseed and now with my modified one.  I'll work it out.  Thanks
[22:07] <designated> blake_r_, i thought maas 1.6 was supposed to be the default on 14.04 but it installs 1.5
[22:07] <blake_r_> designated: 1.6 is trunk current development
[22:07] <blake_r_> designated: trusty is 1.5
[22:07] <blake_r_> designated: we do backport hardware enablement and critical fixes to 1.5
[22:08] <blake_r_> designated: you can install from a ppa if you want 1.6
[22:08] <blake_r_> designated: it is not recommended as its in active development
[22:08] <blake_r_> designated: it can be broken
[22:09] <blake_r_> designated: depending on when you use it, best to stick with 1.5 unless you really need something from 1.6
[22:09] <jfarschman> blake_r_: I appreciate that.  When learning a new tool, predictability is important
[22:09] <blake_r_> jfarschman: np
[22:13] <designated> blake_r, i thought we would be able to bond interfaces in 1.5 according to https://blueprints.launchpad.net/maas/+spec/t-cloud-maas-advanced-networking
[22:14] <designated> blake_r, I haven't seen anything in the documentation explaining how to do this.
[22:15] <designated> blake_r, the ability to do a per node preseed would be extremely beneficial, or the ability to group nodes for a specific preseed, like using a certain preseed based on assigned tags.
[22:15] <blake_r> designated: https://bugs.launchpad.net/maas/+bug/1254755
[22:16] <blake_r> designated: you can do a per node preseed
[22:17] <blake_r> designated: so in /etc/maas/preseeds
[22:17] <blake_r> designated: if you make a file names liek this
[22:17] <blake_r> designated: curtin_amd64_generic_trusty_hostname
[22:17] <blake_r> designated: that is for a custom preseed that uses the curtin install known as "fastpath"
[22:18] <blake_r> designated: so its {prefix}_{node_arch}_{node_subarch}_{release}_{node_name}
[22:18] <blake_r> designated: by tag is not possible, but please make a bug for that, I agree that would be helpful
[22:19] <designated> blake_r, it's to address issues like my storage nodes for example would need different network configuration as well as disk partitioning than say a server that simply runs an application.
[22:22] <jfarschman> designated: I'm using puppet for that sort of thing.  When the config gets complicated and needs to be granular, puppet.
[22:23] <designated> jfarschman, that's great but I might as well manually configure those items, if juju can't request a resource from maas that is configured ready to go.
[22:23] <blake_r> designated: you can also use juju, to do that as well
[22:23] <roaksoax> /query/win 3
[22:25] <designated> blake_r, didn't think of juju handling that configuration, i suppose it would have to happen before installing/configuring any software.
[22:25] <jfarschman> designated: fair enough, but not realistic yet.  One tool to rule them all is still a dream.
[22:25] <blake_r> designated: yeah, you can modify your charm to perform the configuration
[22:25] <blake_r> designated: of create a subordinate charm to do it
[22:26] <designated> crowbar supposedly does all of that, but their dev community doesn't seem very active.  lol  I can't even get crowbar up and running on 14.04 and no one in their irc channel ever speaks...
[22:27] <designated> plus from what I heard, dell stopped developing it.
[22:29] <designated> blake_r, i would prefer to use maas/juju, it seems a lot more versatile, the hesitation was quite simply, I couldn't ever get ahold of anyone to troubleshoot/network with and the documentation hasn't been helpful in a lot of situations.
[22:34] <blake_r> designated: feel free to tag me in a question so I see it, and I can respond
[22:34] <designated> blake_r, thanks for the chat.  you have inspired me to give maas/juju another chance.
[22:35] <blake_r> designated: cool, let me know, if you need any help


[17:24] <grtcdr> Hey guys :)
[17:26] <elacheche[m]> Hey
[17:27] <grtcdr> How are ya?
[17:50] <elacheche[m]> Good
[17:54] <grtcdr> great!
[17:54] <grtcdr> i have a question
[17:55] <grtcdr> any active open source communities out there, like, other than you guys?
[18:06] <elacheche[m]> Communities, I don't think so, check university clubs
[18:08] <grtcdr> Interesting, I don't think there is such a club in my uni.
[18:13] <elacheche[m]> Which is... ?
[19:26] <elacheche[m]> Still here grtcdr: ?
[23:37] <Guest6865> elacheche[m]: Sorry! I forgot we were having a chat!
[23:37] <Guest6865> Ugh... NickServ keeps forgetting my identity
[23:39] <grtcdr> to answer your question, I'm at my 3rd year in ESPRIT
[23:43] <elacheche[m]> grtcdr: ESPRIT Libre is a famous foss clib, we had awesome events with the folks..
[23:43] <elacheche[m]> club*
[23:47] <elacheche[m]> https://www.facebook.com/ClubEspritLibre/?fref=ts
[23:47] <elacheche[m]><EMAIL_ADDRESS>[23:54] <grtcdr> Their last post is from 7 years ago... I don't think they're active (or exist) anymore.
[23:54] <grtcdr> I've certainly never encountered anyone from the club.
[23:55] <elacheche[m]> Try to get i  touch with old folks and kick off the club again ;-)
[23:56] <grtcdr> I located one of its old members
[23:56] <grtcdr> https://github.com/pluzzmo
[23:57] <grtcdr> But he's in france now...
[23:59] <elacheche[m]> Afaik, all the  names I know relocated to europe.. But you ping them anyway
[23:59] <grtcdr> Damn, europe took em all away.
[23:59] <elacheche[m]> Try to send a mail to<EMAIL_ADDRESS>and see if you get an answer
[23:59] <grtcdr> Makes sense though.
[23:59] <grtcdr> elacheche[m]: Will do :)