| jtv | Does anyone know what goes wrong in juju here, and how it might relate to MAAS? I'm completely lost in juju-land. http://askubuntu.com/questions/162255/does-juju-really-need-two-nodes | 04:51 |
|---|---|---|
| rvba | roaksoax: the provisioning server doesn't add /usr/share/maas to the path. Can you modify the PYTHONPATH before you run that command? | 09:10 |
| allenap | rvba: Did you say that you'd had success with http://marcoceppi.com/2012/05/juju-maas-virtualbox/? | 09:57 |
| rvba | allenap: no, I said it looked promising that's all :). | 09:58 |
| marcoceppi | It's not the best way to experience MaaS unfortunately | 09:58 |
| allenap | marcoceppi: Shamefully I haven't read it yet. I'm trying to help out with https://answers.launchpad.net/maas/+question/202414, but I don't have time (none of us do really) to try and reproduce the problem. | 10:05 |
| marcoceppi | IMO The best way to test MaaS is to just spin up the OpenStack DevScript thing. VirtualBox -> OpenStack (physical hardware) differs in experience | 10:07 |
| marcoceppi | rather, test MaaS prior to production deployment | 10:07 |
| hazmat | is there any intent that maas supports additional constraints for 12.10? | 11:22 |
| hazmat | re juju provider constraints | 11:22 |
| hazmat | flacoste, Daviey ^ | 11:22 |
| roaksoax | rvba: howdy.. yeah I eventually figured it out :) | 11:41 |
| roaksoax | jtv: juju requires a bootstrap node.. I guess smoser already clarified it for you | 11:42 |
| smoser | roaksoax is up early. | 11:42 |
| roaksoax | smoser: heh yeah :) | 11:42 |
| jtv | roaksoax: never mind — I had to punt the question. | 11:43 |
| roaksoax | jtv: hehe ok :) | 11:43 |
| roaksoax | rvba: did you submit a patch for that? | 11:43 |
| rvba | roaksoax: for what? The PYTHONPATH thingy? | 11:44 |
| roaksoax | rvba: yeah | 11:45 |
| rvba | roaksoax: no I didn't. | 11:45 |
| roaksoax | rvba: where would be the best place to add it? | 11:48 |
| roaksoax | rvba: cause it seems it fails for the tftp stuff but doesn't fail for anything else | 11:48 |
| rvba | roaksoax: it should be done where the packages run that twisted thingy I think. | 11:50 |
| rvba | package* | 11:50 |
| roaksoax | allenap: could you please take care of that ^^ since you better understand this part of the code :) | 11:52 |
| rvba | roaksoax: allenap will know better indeed. But to me it looks like a packaging question. I mean something that the package' script should set before running the daemon. | 11:55 |
| roaksoax | rvba: right, so what worries me is that right before the tftp stuff was added, we didn't see celeryconfig import errors. As there is lots of other stuff that uses celeryconfig, such as the power stuff | 11:56 |
| roaksoax | rvba: so this shouldn't not be failing to import celeryconfig | 11:56 |
| roaksoax | err s/shouldn't not/shouldn't/ | 11:57 |
| rvba | roaksoax: but that's a new daemon so it seems normal to tweak PYTHONPATH before running it, same as what you've done before running celeryd. | 11:58 |
| roaksoax | rvba: right but that daemon is run by pserv itself | 11:58 |
| roaksoax | rvba: and, correct me if I'm wrong, that daemon being run inside shouldn't it have the path already available? | 11:59 |
| rvba | roaksoax: well, pserv didn't have any dependency on celeryconfig previously. Now it does because of the tftp stuff. | 12:00 |
| roaksoax | rvba: right, but my point being is that pserv also handles the power stuff too right? which means it imports celeryconfig and doesn't fail | 12:00 |
| rvba | roaksoax: no, the power stuff is handled by celeryd. | 12:01 |
| rvba | MAAS talks to celeryd to run the power-related celery tasks. | 12:01 |
| roaksoax | rvba: right, so my point being is this: http://pastebin.ubuntu.com/1087834/ | 12:02 |
| roaksoax | rvba: so If I understand correctly, you are saying that celery handles the power, while ftp is a daemon started by pserv? | 12:03 |
| rvba | roaksoax: allenap will confirm this (he's the only one who's worked on tftp so far) but yes, that's what I think. | 12:04 |
| roaksoax | rvba: there's no variable that contains /usr/share/maas right? | 12:07 |
| rvba | roaksoax: definitely not. | 12:08 |
| roaksoax | rvba: so this should be the fix: http://paste.ubuntu.com/1087846/ right? | 12:09 |
| rvba | Only the packaging knows that thing will end up in /usr/share/maas. | 12:09 |
| roaksoax | rvba: unless we have a varilable that defaults to it :) | 12:10 |
| rvba | roaksoax: I think that this path modification operation should be done right before the process is started rather that in the code itself. | 12:13 |
| rvba | roaksoax: It's the job of the caller to make sure that all the required stuff are present on the path. | 12:13 |
| roaksoax | rvba: i think differently. I think if the daemon is run (pserv), everything that runs under it should know where the stuff it needs is located | 12:14 |
| roaksoax | rvba: i should not need to tell it before running the daemon | 12:15 |
| roaksoax | rvba: as in, this daemon should know where to look | 12:17 |
| rvba | roaksoax: my point is that where things are located depends on the environment (dev environment, prod environment). The process which runs the daemon has all the information to set up the environment properly. It would duplicate the work to have the daemon itself try to guess where things it needs are location. | 12:17 |
| rvba | located* | 12:17 |
| roaksoax | rvba: I agree that it depends on the environment, however, even in such environments, we should not need to manually tell it the PATHS, but rather it should be automatically determined IMHO | 12:18 |
| roaksoax | smoser: how would you handle something like this ^^ | 12:19 |
| rvba | roaksoax: look how we've done with the wsgi stuff: the caller (the wsgi script) was in charge of setting up the path. | 12:19 |
| * smoser reads. | 12:20 | |
| roaksoax | rvba: i agree, but in this case you are starting a daemon under python itself, it does not have its own daemon | 12:21 |
| roaksoax | rvba: that being said, given that that daemon is understed under another, then it should be able to know where everything is | 12:21 |
| roaksoax | rvba: so for me it can be seen as a regression | 12:22 |
| rvba | roaksoax: unless we didn't make celeryconfig.py available to pserv. Because previously we didn't need to do that. Now we do. | 12:22 |
| roaksoax | rvba: right, so we need to make sure celery config is available for everyone that uses it without having to manually set the path | 12:23 |
| roaksoax | rvba: it should rely on a place where everybody can use it, because that's the way how it is being used | 12:23 |
| rvba | roaksoax: same as django's config, that contains MAAS specific information and should not be on the general path, it should only be added to the PYTHONPATH before we run pserv (or celeryd, but we already do that). | 12:24 |
| roaksoax | rvba: what we do with celery, telling the pythonpath on upstart is a hack IMHO. Now, src/provisioningserver/tftp.py is the twisted app that needs to know where celeryd, so it is there where the path should be added | 12:27 |
| roaksoax | rvba: at the end of the day, the thing is if someone installs from source, such as python setup.py install the app should be working without having to provide hacks for it | 12:28 |
| roaksoax | rvba: so there should probably be a setting that tells where celeryconfig is | 12:28 |
| smoser | i don't really understand the problem above completely. but in general, i think its better to have config (or command line arguments) to an application to tell it where stuff is. | 12:29 |
| smoser | i really dont like relying on PYTHONPATH | 12:29 |
| smoser | as environment is hard to manage (as it by default is inherited across forks) | 12:29 |
| smoser | but again, i dont really understand the detail. bug something like http://paste.ubuntu.com/1087846/ doesn't seem like a general program. it seems like part of maas. | 12:30 |
| rvba | smoser: so you agree that the caller should pass on the configuration information. Rather than having the code try to guess where things are. | 12:31 |
| rvba | Whether we use PYTHONPATH or not is another story. | 12:31 |
| roaksoax | rvba: so yes I agree there should be asetting for that. I also think it should try to determine where it relies automatically | 12:32 |
| roaksoax | rvba: in the case of wsgi.py, that is seen as a config file | 12:32 |
| roaksoax | rvba: i have seen wsgi.py files trying to guess where the PATH is | 12:33 |
| roaksoax | rvba: so if the setting is empty, there should be either a default, or a way to try to determine it automatically | 12:34 |
| roaksoax | rvba: based on known install locations | 12:34 |
| rvba | roaksoax: I confess that seems much more complex and error-prone than having the caller (which knows everything about the environment) pass on the right config or set up the right PYTHONPATH. | 12:35 |
| rvba | And let me add that it's what we've done so far: wsgi.py, the prod caller script, set it up with the prod path. | 12:36 |
| roaksoax | rvba: right, but in this the caller script is maasps.py | 12:36 |
| rvba | The dev script (services/webapp/run) set up it up with the dev PYTHONPATH | 12:36 |
| rvba | sets* | 12:37 |
| smoser | if we can, yeah, it makes sense to have default configs. and ideally an installed application isn't completely broken. | 12:37 |
| smoser | and one installed by ubuntu should not have to be told where it is installed to | 12:37 |
| smoser | (so that part of "automatic" i agree with) | 12:37 |
| rvba | It doesn't make sense to me to hard code platform-specific path in the code itself. But I'm no expert so I'm ok to be told to do otherwise. | 12:38 |
| roaksoax | rvba: so could pserv.yaml contain this information then? | 12:38 |
| jtv | I'm off, people. See you tomorrow! | 12:39 |
| roaksoax | rvba: but that's what happens in all software I've seen so far, you "hardcode" a location, but if a different installation location is selected, the software should know where it is | 12:39 |
| rvba | roaksoax: that would work, because there is a pserv.yaml for the prod environment and another one for the dev environment. | 12:40 |
| roaksoax | rvba: example of this is installing between different distributions. Some software might default to /usr/local/lib in RHEL for example, and in ubuntu we use /usr/lib/. So that software needs to know where its stuff ended up installing | 12:40 |
| rvba | roaksoax: exactly, so something outside of the software should tell it where things are. It's not the responsability of the software to try to guess the possible locations. | 12:41 |
| roaksoax | rvba: I agree | 12:42 |
| roaksoax | rvba: but IMHO, this case is different because its being run under PYTHONPATH "importing" a "python module" | 12:42 |
| rvba | roaksoax: right, I admit that's a bit special. | 12:42 |
| roaksoax | rvba: so we are in agreement then. I'd say pserv.yaml would probably be the best place to "change" the installation path then | 12:43 |
| rvba | roaksoax: let's wait for allenap to come back and see what he thinks about that. He's the one who decided to call the tftp stuff from within the code. | 12:43 |
| roaksoax | rvba: ok | 12:44 |
| allenap | Okay, what's up? | 12:44 |
| rvba | roaksoax: that makes sense, although I would still prefer to have those path modifications made by the process launching the initial process. | 12:44 |
| allenap | Shall I just read the scrollback? | 12:44 |
| rvba | allenap: yes | 12:44 |
| * rvba grabs a bite. | 12:45 | |
| roaksoax | rvba: right, that would be telling upstart where pythonpath is | 12:45 |
| rvba | roaksoax: yep. | 12:45 |
| roaksoax | rvba: which I certainly trying to avoid | 12:46 |
| rvba | roaksoax: I can see that :) | 12:46 |
| roaksoax | rvba: cause it really is a hack | 12:46 |
| roaksoax | rvba: in the case of celery is a must do | 12:46 |
| rvba | roaksoax: may I ask why this is considered a hack? | 12:49 |
| roaksoax | rvba: I think that the daemon should run, and if it does not find a config, it should fail | 12:54 |
| roaksoax | rvba: celeryd imports a config as running a python script, which makes us tell it where the config is | 12:54 |
| roaksoax | the bad things is that we have to tweak the pythonpath | 12:54 |
| roaksoax | in order for it to work | 12:54 |
| roaksoax | we shouldn't really need to tweak it, but rather simply tell it where the config is | 12:55 |
| rvba | roaksoax: indeed, but it seems to be rather common for python-based software to use python modules as configuration files (see Django, celery). | 12:57 |
| roaksoax | rvba: it does, but nobody is perfect :) | 12:57 |
| rvba | roaksoax: and that doesn't tell me why it's bad to tweak the pythonpath. Where tweak = add one item to it to tell the software where it's config is. | 12:58 |
| rvba | s/it's/its/ | 12:58 |
| rvba | Changing the pythonpath like this, in the context of a specific process seems pretty benign to me. | 12:58 |
| rvba | But maybe I'm missing the big picture. | 12:59 |
| roaksoax | rvba: but yeah, from my personal point of view, having to tweak pythonpath for it to find the config, is a hack. It would be much simpler to tell where a config is, such as yaml, and let celery code import tha varilables and make then available ... I however, don't know anmythjing about celery so I wouldn't know why they preferred doing it that way | 12:59 |
| roaksoax | rvba: so, from my point of view, telling where pythonpath is similar to running a chroot | 13:00 |
| roaksoax | or to running an applicaion in a chroot, | 13:01 |
| roaksoax | but we are obviuoulsy not doing so | 13:01 |
| rvba | roaksoax: agreed, using flat files (a la yaml) would be more clean. But since we're dealing with framework which use python modules to store configuration options, we have to adapt to the way they work and tweak the pythonpath. | 13:02 |
| roaksoax | rvba: indeed | 13:02 |
| rvba | frameworks* even (Django + Celery) | 13:02 |
| roaksoax | rvba: right, but in django, we basically tell wsgi where to start from where almost everything is is publicly available in pythonpath | 13:05 |
| roaksoax | rvba: from "within" the application | 13:05 |
| roaksoax | rvba: so we are adding a path for that particular "instance" | 13:05 |
| roaksoax | rvba: while in celery, we are doing it "externally", from the upstart job | 13:06 |
| rvba | I don't consider wsgi.py to be part of the application, it's really the equivalent of an upstart job from within apache. | 13:06 |
| rvba | roaksoax: isn't an upstart job also a particular "instance"? | 13:07 |
| smoser | rvba, if i was looking to grab maas trunk and try to use it | 13:08 |
| smoser | is there any doc that covers that? | 13:08 |
| smoser | i'll just run it on an instance, so i dont care if i have to install stuff as root or whatever, just want to get the full path working as much as possible. | 13:09 |
| roaksoax | smoser: i have quantal maas working | 13:09 |
| roaksoax | smoser: you should be able to use it. I'm looking to update it today after this stuff gets fixed | 13:10 |
| rvba | smoser: that's really something that is unsupported, untested and undocumented. The only way to run MAAS from source is to run what we call the dev instance, with local services and a test database but you won't be able to deal with real nodes. | 13:11 |
| roaksoax | rvba: it is too | 13:11 |
| smoser | rvba, ok. thats fine, but at least please realize that you just said "running this code is unsupported, untested and undocumented" | 13:12 |
| smoser | i literally laughed out loud. and i try not to do that on irc. | 13:12 |
| rvba | smoser: no, that's not what I said. | 13:12 |
| rvba | smoser: I'm sure there is a way to do that but it will require fiddling with the config a bit. But we've always used the packaged version of MAAS to try things out with real nodes. | 13:13 |
| czajkowski | if anyone can help the user who has asked a question on AU that would be great. http://askubuntu.com/questions/162255/does-juju-really-need-two-nodes | 13:16 |
| rvba | smoser: we've designed the dev environment to be completely isolated from the rest of the system, so it's contradictory with actually dealing with real nodes. | 13:16 |
| roaksoax | allenap: any thoughts? | 13:26 |
| allenap | roaksoax: I was otp; I'm just reading the scrollback now... and there's a *lot* of it. | 13:26 |
| roaksoax | heheh | 13:35 |
| roaksoax | rvba: where is it that twistd logged by default? | 13:39 |
| allenap | roaksoax, rvba: I haven't read everything, but... the tftp server (pserv as a whole) doesn't need access to the celeryconfig module. We should move the config out of that file. I just did it that way because it was already there. | 13:46 |
| allenap | Personally I *hate* celeryconfig and DJANGO_SETTINGS_MODULE, but we have to live with the things. | 13:47 |
| allenap | I would like to define things like TFTPPATH in pserv.yaml, or a more general maas.yaml (does not exist), and then these config module aberrations can pull the config in from there. | 13:48 |
| roaksoax | allenap: so tftppath.py will not import celeryconfig then? | 13:49 |
| roaksoax | in the future? | 13:49 |
| allenap | Also, pserv is all about Cobbler and, now, TFTP. The Cobbler stuff will go, and pserv will simply be a container for the TFTP server. We can also use it to host other Twisted services, but there aren't any others that need it right now. | 13:50 |
| allenap | roaksoax: No, we should get rid of that. | 13:50 |
| roaksoax | allenap: ok, that's what I was asking :). Now, if pserv is in place, I think the tftproot should rely in pserv.yaml | 13:50 |
| roaksoax | the config option | 13:51 |
| allenap | celeryconfig *should* die, but celeryd needs it. IMO, we should put only enough in there for celeryd to start, then put MAAS specific config elsewhere. | 13:51 |
| allenap | roaksoax: Agreed. | 13:51 |
| allenap | roaksoax: I'll fix that now; I assume it's blocking you? | 13:51 |
| roaksoax | allenap: I'm gonna provide a temporary patch for it to work now, but will remove once your fix is in trunk :) | 13:52 |
| allenap | Cool. | 13:52 |
| * allenap gives up hope of doing QA today ;) | 13:52 | |
| roaksoax | rvba: btw.. I think we can ditch 1 of the IPMI options from the UI and just keep IPMI lan | 13:52 |
| rvba | roaksoax: I've got no problem with that. As you know, they were simply stolen from cobbler. If there is a good reason to merge two of the options into one, I'm fine with it. | 13:53 |
| roaksoax | rvba: ok cool :) I'll re-verify (not an easy task with no ipmi devices to play with_ | 13:54 |
| roaksoax | Daviey: do we have any lab with IPMI that I can play with? | 13:55 |
| roaksoax | err | 13:55 |
| roaksoax | rvba: so what do you think so far? | 14:06 |
| roaksoax | rvba: http://paste.ubuntu.com/1088010/ | 14:06 |
| roaksoax | robbiew: howdy!! so ipmi worked like a charm then... was it using the fulll template or the minimized one? | 14:06 |
| rvba | roaksoax: I need to step out bit a bit, I'll have a look when I'll be back... in ~40 minutes. | 14:07 |
| roaksoax | sure thanks! | 14:07 |
| robbiew | RoAkSoAx: full | 14:09 |
| robbiew | but they didn't shutdown on a terminate-environment | 14:10 |
| robbiew | whoops...destroy-environment | 14:10 |
| roaksoax | robbiew: alright! I'll look into that | 14:10 |
| robbiew | cool | 14:14 |
| rvba | robbiew: I'm back. That pastebin looks good to me. I can give you a hand with writing the tests if you want. | 14:57 |
| rvba | err, roaksoax | 14:57 |
| robbiew | lol | 14:57 |
| rvba | :) | 14:57 |
| robbiew | too many r's | 14:57 |
| rvba | yep | 14:57 |
| roaksoax | rvba: i already wrote them, they seem to "work" :) | 14:58 |
| roaksoax | but sure | 14:58 |
| roaksoax | rvba: ok so in cobbler ipmilan uses fence_ipmilan while ipmi uses ipmitool directly | 15:04 |
| roaksoax | rvba: fence_ipmilan requires ipmitool | 15:05 |
| roaksoax | rvba: so I guess we could just stay with ipmitool | 15:06 |
| rvba | roaksoax: do you know what fence_ipmilan adds to ipmitool? | 15:06 |
| rvba | (I'm just curious) | 15:06 |
| roaksoax | rvba: that's what I'm actually looking for | 15:06 |
| roaksoax | rvba: i'm guessing it was just created to be used in RHCS, isntead of using ipmitool directly | 15:07 |
| roaksoax | rvba: i don't think it adds anything significant | 15:08 |
| roaksoax | rvba: i, however, am thinking that we might need to add a box too allow sending extra commands | 15:09 |
| roaksoax | allenap: still around? | 18:30 |
| allenap | roaksoax: Just back. What's up? | 19:18 |
| roaksoax | allenap: i forgot :) | 19:19 |
| allenap | Haha :) | 19:19 |
| roaksoax | allenap: still around? I remembered :) | 20:25 |
| roaksoax | allenap: so I won't forget... did the maintainer pulled your changes yet? | 20:38 |
| roaksoax | python-tx-tftp | 20:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!