[13:40] <smoser> bad design (and implementation) in openstack
[13:42] <smoser> each time you do a request to the metadata service it ends up in lots of messages on the bus to get the information. at points you could almost DOS a openstack installation by just hitting the metadata server.
[13:42] <smoser> meena: ^
[13:44] <smoser> https://github.com/cirros-dev/cirros/issues/8
[13:45] <smoser> that is a very typical discussion on the topic.
[13:45] <smoser> i'd like to highlight this comment:
[13:45] <smoser> In these test runs, how long did it take cirros to boot? Lets say it took 2 minutes. That means you booted virtual hardware (bios, kernel,disk, ....) in 2 minutes, but a HTTP couldn't be satisfied in 10 seconds?
[15:45] <mock> Question: I am adding the package_update: true to my cloud-config userdata. My package manager is yum. Will this be the equivalent of a yum update or yum update --security? And if not the second, is there a cloud-init way to do the security only update or do I just need to runcmd the command.
[15:45] <mock> ?
[16:17] <Odd_Bloke> mock: I don't believe it will be the second, and I don't believe that there is a cloud-init way to express a security-only update.
[16:19] <Odd_Bloke> In the apt world, or Ubuntu at least, security updates aren't special at the package manager level; if you only want security updates, then you change the package sources to only include security repos and then `apt update; apt upgrade` as normal.)
[16:20] <Odd_Bloke> So I think this is a case where the "lowest common denominator" package management module can't express such a requirement (though I haven't given it too much thought and would happily be contradicted).
[16:27] <mock> Ok, thanks
[16:28] <mock> I will use the runcmd avenue