| smoser | blackboxsw: well, its that there is no python | 01:56 |
|---|---|---|
| smoser | in rawhide | 01:56 |
| smoser | well, we could buildpend on python2 and use python2. | 01:56 |
| smoser | thats probably the easiest path out of it... to just build python2 for fedora, but we really want to be doing python3 there. | 01:57 |
| blackboxsw | yet on successes I also see the missing python log | 01:58 |
| blackboxsw | https://copr-be.cloud.fedoraproject.org/results/blackboxsw/cloud-init/fedora-rawhide-i386/00776423-cloud-init/build.log.gz | 01:59 |
| smoser | all by myself tomorrow :) | 01:59 |
| smoser | wll that is odd. | 01:59 |
| blackboxsw | yet in this success case the diff is logged from sh instead of /var/tmp/rpm-tmp.v0 etc | 01:59 |
| blackboxsw | BUILDSTDERR: sh: /usr/bin/python: No such file or directory | 01:59 |
| smoser | i think that is just an error in their build system | 01:59 |
| smoser | that it didn't catch failure | 01:59 |
| blackboxsw | get a few of those and then it goes on building | 02:00 |
| smoser | if you're saying that url is a success | 02:00 |
| smoser | hm... | 02:00 |
| blackboxsw | yeah the last one was a success and continued building perBuilding target platforms: i686 | 02:00 |
| blackboxsw | " | 02:00 |
| blackboxsw | it's strange, I'll try kick off a build myself from tip pre-get-linux-distro to see if it passes. here's the proper "pass" linked logs from cloud-init-dev's run before my changeset landed in tip https://copr-be.cloud.fedoraproject.org/results/@cloud-init/cloud-init-dev/fedora-rawhide-i386/00774784-cloud-init/build.log.gz | 02:03 |
| blackboxsw | that differs from my local failed build attempt https://copr-be.cloud.fedoraproject.org/results/blackboxsw/cloud-init/fedora-rawhide-i386/00776423-cloud-init/build.log.gz | 02:04 |
| smoser | how'd you local build ? | 02:05 |
| blackboxsw | I local built a source rpm and uploaded it via copr UI in the "new Build" dialog ./tools/run-container --source-package centos/7 | 02:13 |
| blackboxsw | ok gotta run | 02:14 |
| smoser | oh. right. ok. i didn't understand that as "local" | 02:14 |
| caribou | smoser: I just pushed modifications for my MR. For some reason Jenkins did not trigger after the failed build | 13:23 |
| caribou | but I have one issue that I'd like to bounce by you people | 13:23 |
| caribou | The network config gets generated on each boot, but, even though I see bring_up=True, the network config does not get applied (i.e. the IPv6 portion of it) | 13:25 |
| caribou | I traced it down to _write_network_config that returns the result of _supported_write_network_config, which always happens to be an empty list | 13:31 |
| caribou | Since _bring_up_interfaces() scans that list, it never brings up any device | 13:35 |
| caribou | I hope I'm making some sense | 13:35 |
| smoser | caribou: you have to be in a group to get it to autmatically run for you | 13:57 |
| smoser | dont know if you're in it or not. | 13:57 |
| caribou | well, usually it runs on each new commit | 13:58 |
| caribou | the first one failed then I fixed & pushed again | 13:58 |
| smoser | caribou: bring_up=True should actually be removed. we dont do anything with it now, and i think its not really supposed to get called (but i'd have to dig to remember) | 13:58 |
| smoser | it was kind of garbage from long time a go. | 13:58 |
| smoser | what is supposed to happen is that cloud-init in local mod renders the networking configuration | 13:58 |
| smoser | and then the operating system brings it all up as it would if that was writtenb efore the boot. | 13:59 |
| caribou | hmm, that'll explain it, I moved it back to DEP_NETWORK | 13:59 |
| caribou | hmm, then that means that I still need to rely on EphemeralDHCP since I need to fetch the metadata to the the IPv6 info | 14:00 |
| smoser | caribou: yes. you do need to use ephemeraldhcp | 14:02 |
| smoser | caribou: maybe some background info ... | 14:03 |
| smoser | - local runs before networking is brough up by the OS | 14:03 |
| caribou | got that | 14:03 |
| smoser | - cloud-init.service runs *after* networking is brought up by the OS | 14:03 |
| smoser | - we want to guarnatee that things that need networking can use it when the OS says it is up. | 14:04 |
| smoser | ie, we do not want cloud-init to go bouncing the interfaces | 14:04 |
| caribou | k | 14:04 |
| smoser | so we write networking before the OS brings it up and let the OS bring it up | 14:05 |
| smoser | with future events we may have cloud-initn bounsing networking | 14:05 |
| caribou | So the use of EventType is to assure that the network_config in the ds will run at each boot and not on the initialone | 14:05 |
| smoser | or otherwise telling the OS to apply new networking of some sort. | 14:05 |
| smoser | right. | 14:05 |
| caribou | ok got it | 14:05 |
| caribou | I'll fix it up as such & push again | 14:06 |
| caribou | thanks for the details | 14:06 |
| smoser | users of scaleway will by default have cloud-init render networking on every boot | 14:06 |
| smoser | they will be able to disable that | 14:06 |
| smoser | but should they do that... then they wont get networking rendered on boot, and bad things might happen. | 14:06 |
| smoser | the reason we allow them to disable that behavior. | 14:06 |
| smoser | a.) cloud-init has not behaved like this in the past (backwards compat desire) | 14:07 |
| smoser | b.) they may have other ways of building things on top . perhaps they bring up a vpn or something, and cloud-init would cause issues with that if it modified the networking configuraitoin on reboot. | 14:07 |
| caribou | good, understood | 14:08 |
| caribou | Grrr, I accidentaly delete my MR branch off LP :-( | 14:32 |
| caribou | smoser: any chance of tying a new branch on the original MR ? Or I should just close this one & create a new one ? | 14:33 |
| smoser | caribou: "tying a new branch?" | 14:44 |
| smoser | i suspect if you just push the branch again with same name it might work | 14:45 |
| caribou | smoser: doesn't look like it, maybe I try ro resubmit | 15:12 |
| smoser | ok | 15:18 |
| caribou | smoser: sorry, had to delete & resubmit it was referring to the dead branch | 15:30 |
| smoser | caribou: i'll get a look at that today. | 15:37 |
| powersj | smoser: are you using blackboxsw's gce instances? | 21:18 |
| smoser | powersj: no. | 21:22 |
| * powersj blows them away then | 21:22 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!