Hi all, Here are some of my thoughts on the Austin summit sessions. Don't hesitate to ask questions or fix my misunderstanding. I'll try to keep it short, please also refer to the etherpads for more details (sometimes :)): https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Heat
Release model ---------------------- We'll continue to as usual in the cycle-with-milestones, and investigate having a shorter feature freeze for more flexibility. Default to convergence --------------------------------- Now's the time to enable it by default. We have a bunch of small things to fix in tests, but the main point is to check that projects using Heat work fine. If we can pull it off I hope to do the switch by newton-1, so in 3 weeks. That we'll leave us with plenty of time for feedback and improvements Convergence improvements ---------------------------------------- There are some changes that we can now make to use convergence, like not polling on hooks, which would be nice. But the main part is to work on performance, to close the gap with the legacy engine. There is at least one issue with messaging that we need to investigate. Performance ------------------ This is what I hope will be a focus for the cycle, especially with regard to large stacks. We have one major issue with the way we handle files in the environment, which clogs our memory usage. That fix is in good progress, once merged we'll find some smaller things to incrementally improve on. We need to measure more to be able detect regressions early and test new approaches. I'll see with infra if we can get a periodic job for that and how storage works. Continuous observer ------------------------------ The outcome of that session was basically that we don't want to do this in Heat, at least for the time being. First, we're missing the notifications on the resources that we spawn. Until that functionality exists in OpenStack, it'll be tough to write a generic solution. Then, it's a policy driven mechanism, and you need to be able to customize how to react to failure on resources. So for now we want to document how you can use the current APIs outside of Heat to achieve this, and make sure that it works fine. HOT parser ----------------- This was somewhat tricky subject, as we tried to mix external template validation and template building. The former is difficult to pull off without being wrong, duplicate efforts, or slowing down development too much. It may be possible to do some basic validation, and we'll see if we can create a reusable library for that. The latter is a bit more clear (at least to me), and I hope something will be available for Newton. New heatclient commands -------------------------------------- We listed improvements that can be made now that we completed the move to OSC. I'm really interested on a way to get failures more easily, as it's a common pattern and it'll improve user experience quite a bit. Software deployment refinements ------------------------------------------------ We decided to add a new property on SoftwareConfig indicating the inputs which creates a replacement. We also need to improve timeouts management, and allow the ability to send data when deployments are in progress to get debug information. Using DLM ---------------- We managed to not talk about ZooKeeper too much :). We want to remove the database locks that we have and use tooz instead. The key is to provide a nice upgrade path, so starting with the locks use for convergence seems easier. If it turns out to be painless, we'll move the stack locks from the legacy engine as well. Validation improvements ----------------------------------- Many subjects were mentioned here, with regard to the HOT parser topic as well. The change I'd like to see is using placeholder objects everywhere instead of None, so that we can clarify validations of non-resolved data. Integration tests ----------------------- Not much to say on that subject. We want to move to use tempest plugin, and the tempest runner, and remove as much custom code that we have as possible. Thanks, -- Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev