smoserharlowja, around ?01:13
smoseri've something like this01:14
smoserwhich is clearly lame compared to what harlowja would come up with01:14
smoserbut i want to be able to get the values() of this "enum" like thing01:14
harlowjajust use the enum module?01:14
smoserthat would be the easiest thing.. but if i can avoid the depends... and still work python2.6 i'd like to01:15
harlowjathen i guess yours is sorta sneaky for that01:17
harlowjaseems ok, due to 2.6 and desires to minimize depends01:19
smoserwell, the pain was that i wanted to then check if a user provided string was a valed entry01:19
smoserbasicaly, if it were a dict, i wanted to:01:20
smoser if foo in thatthing.keys()01:20
harlowjanot work?01:22
smoserwell, no. because keys() isn't hooked up to anyting01:27
harlowjaah, right01:27
harlowjaone sec01:33
smoserharlowja, just when you thought i could not get any more ghetto01:55
harlowjaya, closer to where i was going to go, ha01:56
harlowjahttp://paste.openstack.org/show/596960/ smoser02:10
harlowjais what i got02:10
harlowjamay be good enough for u, may not be, ha02:10
harlowjanot sure why __contains__ wouldn't work (but it didn't, ha)02:13
smoseryeah, thanks.02:13
* smoser turns to pumpkin02:14
smoserthank you!02:14
burgerkHi, question ...  using cloud-init in Ubuntu 16.10, is it a requirement now that the datasource with network be available at all times and not just at first boot for network setup ?   It appears that if I remove the datasource and reboot the VM, I lose static network settings15:29
rharperburgerk: I think you may need to use the manual_cache_clean: True setting to indicate that you want to re-use the existing instance data;  can you clarify what you mean by losing static network settings?  was that part of your user-data?15:45
rharperhttps://bugs.launchpad.net/cloud-init/+bug/1596013  has more details15:45
burgerkif I remove the datasource and then reboot the VM, the static IP of the VM is no longer set15:46
burgerkinformation that would typically go in the interfaces file that now goes in /etc/network/interfaces.d/50-cloud-init.cfg15:48
burgerkrharper: being able to snapshot the instance is important, so I don't want to have to manually clean the cache15:53
rharperburgerk: does the bug above capture your issue (other than not wanting to use manual-cache-clean)?  50-cloud-init.cfg is auto-generated, so I'm unsure of how you're getting static network configuration into it without using cloud-init network: config  ?16:06
rharpersmoser: which reminds me, I think we need to import some network config documentation from curtin; I'm not seeing it in the cloud-init RTD16:07
burgerkrharper: yes that does appear to be the same issue.  Here is my scenario, on initial boot, datasource exists ( ConfigDrive ) and set the static network information as expected for first boot.   At some later point, the config drive is removed and the VM is rebooted.  When the VM reboots that network information from the first boot is now gone and it attempts to connect as DHCP16:10
smoserrharper, yes, we probably should pull it over.16:17
smoserburgerk, what is the datasource you're using ?16:18
smoseron openstack ?16:18
smoseryou should not depend on the metadata service on subsequent boots there.16:18
smoserwait... maybe...16:19
smoserlet me see.16:19
smoseryou should be ok... if your system's uuid (in dmi data) matches your instance id16:20
smoseras it does on openstack provided vms16:20
rharpersmoser: IIUC, the use-case is to snapshot that and move to new instance16:20
smoserwell, then its a new instance!16:21
smoserand it should go get new network data16:21
smoserother wise you'd alway have the same static ip address everywhere.16:21
burgerkthings work fine on first boot, network info is rewritten.16:22
burgerkthe problem is if config drive is removed and there is no datasource.  The network config file is cleared and the information to repopulate is gone16:24
burgerkI did not expect interfaces.d/50-cloud-init.cfg to be cleared on every reboot16:25
burgerksmoser, is that the expected behavior?  to rewrite networking on every boot, not just first boot now? ( previously using cloud-init 0.7.7 )16:26
smoserit should rename devices, but should not re-render that file16:30
smoseryou should take that "not a new instance. network config is not applied"16:31
smoserburgerk, can you do me a favor16:32
smosera.) boot an instance with disk attached16:32
smoser  mkdir orig-boot; mv /var/log/cloud-init* orig-boot/ ; cp /run/cloud-init -a orig-boot/16:33
smoserb.) detach disk, reboot16:33
smoserc.) re-do copy logs like in 'a' but to second-boot16:33
smoserburgerk, this is actually  openstack ?16:44
smoseror your local usage of config drive16:44
burgerkstraight openstack16:44
smoserrharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/31603316:51
rharpersmoser: lol @ Genuine16:54
smoserand https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/31583217:01
=== shardy is now known as shardy_afk
burgerksmoser, I collected the logs you requested, but in the process, I think I may have found what is causing this issue.22:44
burgerkwouldn't deleting that file make it appear to be first boot again after the reboot?22:45

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