smoserblackboxsw: well, its that there is no python01:56
smoserin rawhide01:56
smoserwell, we could buildpend on python2 and use python2.01:56
smoserthats probably the easiest path out of it... to just build python2 for fedora, but we really want to be doing python3 there.01:57
blackboxswyet on successes I also see the missing python log01:58
smoserall by myself tomorrow :)01:59
smoserwll that is odd.01:59
blackboxswyet in this success case the diff is logged from sh instead of /var/tmp/rpm-tmp.v0 etc01:59
blackboxswBUILDSTDERR: sh: /usr/bin/python: No such file or directory01:59
smoseri think that is just an error in their build system01:59
smoserthat it didn't catch failure01:59
blackboxswget a few of those and then it goes on building02:00
smoserif you're saying that url is a success02:00
blackboxswyeah the last one was a success and continued building perBuilding target platforms: i68602:00
blackboxsw "02:00
blackboxswit'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.gz02:03
blackboxswthat 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.gz02:04
smoserhow'd you local build ?02:05
blackboxswI local built a source rpm and uploaded it via copr UI in the "new Build" dialog ./tools/run-container  --source-package centos/702:13
blackboxswok gotta run02:14
smoseroh. right. ok. i didn't understand that as "local"02:14
caribousmoser: I just pushed modifications for my MR. For some reason Jenkins did not trigger after the failed build13:23
cariboubut I have one issue that I'd like to bounce by you people13:23
caribouThe 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
caribouI traced it down to _write_network_config that returns the result of _supported_write_network_config, which always happens to be an empty list13:31
caribouSince _bring_up_interfaces() scans that list, it never brings up any device13:35
caribouI hope I'm making some sense13:35
smosercaribou: you have to be in a group to get it to autmatically run for you13:57
smoserdont know if you're in it or not.13:57
caribouwell, usually it runs on each new commit13:58
caribouthe first one failed then I fixed & pushed again13:58
smosercaribou: 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
smoserit was kind of garbage from long time a go.13:58
smoserwhat is supposed to happen is that cloud-init in local mod renders the networking configuration13:58
smoserand then the operating system brings it all up as it would if that was writtenb efore the boot.13:59
caribouhmm, that'll explain it, I moved it back to DEP_NETWORK13:59
caribouhmm, then that means that I still need to rely on EphemeralDHCP since I need to fetch the metadata to the the IPv6 info14:00
smosercaribou: yes. you do need to use ephemeraldhcp14:02
smosercaribou: maybe some background info ...14:03
smoser - local runs before networking is brough up by the OS14:03
caribougot that14:03
smoser - cloud-init.service runs *after* networking is brought up by the OS14: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 interfaces14:04
smoserso we write networking before the OS brings it up and let the OS bring it up14:05
smoserwith future events we may have cloud-initn bounsing networking14:05
caribouSo the use of EventType is to assure that the network_config in the ds will run at each boot and not on the initialone14:05
smoseror otherwise telling the OS to apply new networking of some sort.14:05
caribouok got it14:05
caribouI'll fix it up as such & push again14:06
caribouthanks for the details14:06
smoserusers of scaleway will by default have cloud-init render networking on every boot14:06
smoserthey will be able to disable that14:06
smoserbut should they do that... then they wont get networking rendered on boot, and bad things might happen.14:06
smoserthe reason we allow them to disable that behavior.14:06
smosera.) cloud-init has not behaved like this in the past (backwards compat desire)14:07
smoserb.) 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
caribougood, understood14:08
caribouGrrr, I accidentaly delete my MR branch off LP :-(14:32
caribousmoser: any chance of tying a new branch on the original MR ? Or I should just close this one & create a new one ?14:33
smosercaribou: "tying a new branch?"14:44
smoseri suspect if you just push the branch again with same name it might work14:45
caribousmoser: doesn't look like it, maybe I try ro resubmit15:12
caribousmoser: sorry, had to delete & resubmit it was referring to the dead branch15:30
smosercaribou: i'll get a look at that today.15:37
powersjsmoser: are you using blackboxsw's gce instances?21:18
smoserpowersj: no.21:22
* powersj blows them away then21:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!