Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API
On Thu, Nov 21, 2013 at 12:18 PM, Zane Bitter zbit...@redhat.com wrote: On 20/11/13 23:49, Christopher Armstrong wrote: https://wiki.openstack.org/wiki/Heat/AutoScaling#LBMember.3F Basically, the LoadBalancerMember resource (which is very similar to the CinderVolumeAttachment) would be responsible for removing and adding IPs from/to the load balancer (which is actually a direct mapping to the way the various LB APIs work). Since this resource lives with the server resource inside the scaling unit, we don't really need to get anything _out_ of that stack, only pass _in_ the load balancer ID. I see a couple of problems with this approach: 1) It makes the default case hard. There's no way to just specify a server and hook it up to a load balancer like you can at the moment. Instead, you _have_ to create a template (or template snippet - not really any better) to add this extra resource in, even for what should be the most basic, default case (scale servers behind a load balancer). First, the design we had implied that we had a template all the time. Now that changed, it does make things a bit harder than the LoadBalancerNames list, but it's still fairly simple to me, and brings a lot of flexibility. Personally, my idea was to build a generic API, and then build helpers on top of it to make common cases easier. It seems it's not a shared view, but I don't see how we can do both at once. 2) It relies on a plugin being present for any type of thing you might want to notify. At summit and - to the best of my recollection - before, we talked about scaling a generic group of resources and passing notifications to a generic controller, with the types of both defined by the user. I was expecting you to propose something based on webhooks, which is why I was surprised not to see anything about it in the API. (I'm not prejudging that that is the way to go... I'm actually wondering if Marconi has a role to play here.) We definitely talked about notifications between resources. But, putting it in the way of the autoscaling API would postpone things quite a bit, whereas we don't really need it for the first phase. If we use the member concept, we can provide a first integration step, where the only missing thing would be rolling updates. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Proposal for new heat-core member
On Fri, Oct 25, 2013 at 9:12 PM, Steven Dake sd...@redhat.com wrote: Hi, I would like to propose Randall Burt for Heat Core. He has shown interest in Heat by participating in IRC and providing high quality reviews. The most important aspect in my mind of joining Heat Core is output and quality of reviews. Randall has been involved in Heat reviews for atleast 6 months. He has had 172 reviews over the last 6 months staying in the pack [1] of core heat reviewers. His 90 day stats are also encouraging, with 97 reviews (compared to the top reviewer Steve Hardy with 444 reviews). Finally his 30 day stats also look good, beating out 3 core reviewers [2] on output with good quality reviews. Please have a vote +1/-1 and take into consideration: https://wiki.openstack.org/wiki/Heat/CoreTeam +1! -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Autoscale and load balancers
On Wed, Oct 2, 2013 at 11:07 PM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: A way to achieve the same behavior as you suggest but less verbose would be to use relationships in HOT. We had some discussion about relationships earlier this year and in other contexts, but this would fit here very well. And I think you express a similar idea on the wiki page you linked above. The model could look like: resources: server1: type: OS::Nova::Server server2: type: OS::Nova::Server loadbalancer: type: OS::Neutron::LoadBalancer # properties etc. relationships: - member: server1 - member: server2 From an implementation perspective, a relationship would be implemented similar to a resource, i.e. there is python code that implements all the behavior like modifying or notifying source or target of the relationship. Only the look in the template is different. In the sample above, 'member' would be the type of relatioship and there would be a corresponding implementation. I actually wrote up some thoughts about possible notation for relationship in HOT on this wiki page: https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider We have such concepts in TOSCA and I think it could make sense to apply this here. So when evolving HOT we should think about extending a template from just having resources to also having links (instead of association resources which are more verbose). Thanks for the input, I like the way it's structured. In this particular case, I think I'd like the relationships to be on server instead of having a list of relationships on the load balancer, but the idea remains the same. I didn't grasp completely the idea of components just yet, but it seems it would be a useful distinction with resources here, as we care more about the actual application here (the service running on port N on the server), rather than the bare server. It becomes the responsibility of the application to register with the load balancer, which it can do in a more informed manner (providing the weight in the pool for example). We just need a concise and explicit way to do that in a template. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Autoscale and load balancers
Hi all, There is a small but important part of the autoscale design described in https://wiki.openstack.org/wiki/Heat/AutoScaling that we'd like to discuss to make sure everybody is on the same page. Namely, the relationship between an autoscaling group and a load balancer. In the current system, a group has references to load balancers, and signals them when the group changes, sending it the list of servers in the group. This creates an implicit interface between groups and load balancers that we didn't model well, and is awkward for third-party load balancers. In the new design, the suggestion is to have an intermediate resource which models the relationship between the load balancer and its members. This resource would be instantiated every time an instance is added (or removed) and would notify the load balancer. There are some more details here: https://wiki.openstack.org/wiki/Heat/AutoScaling#Load_Balancers. Pros: * Remove load balancer specific code from the autoscale implementation. * Map nicely to the neutron lbaas code, which has a 'add-member' API. * Provide a more generic model for notifying systems of servers allocation. Cons: * Make the template a bit more verbose. We have some ideas on how to alleviate the verbosity concern, for example by creating a LoadBalancerServer resource which would embed a Server and a LoadBalancerMember resource. But the template being Heat's main UI, it's important to get a good story here. Thoughts? -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Review] Use of exception for non-exceptional cases
On Fri, Jul 12, 2013 at 5:33 PM, Monty Taylor mord...@inaugust.com wrote: On 07/11/2013 05:43 AM, Thomas Hervé wrote: On Thu, Jul 11, 2013 at 1:49 AM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: I'd like top-post and hijack this thread for another exception related thing: a) Anyone writing code such as: try: blah() except SomeException: raise SomeOtherExceptionLeavingOutStackContextFromSomeException should be mocked ruthlessly. i don't think mocking is a good way to convey your point. Losing tracebacks is not great, but having an API raising random exceptions is probably worse. Can you develop? I have learned that I may have mis-read your last three words due to translation problems. You were not asking if I had the ability to write code, rather you were asking if I could elaborate. Ah thanks, and sorry for the frenchism. I think I understand your point now, which is not so much about tracebacks but about context in the wide sense, ie enough information to understand what's going on. I've found that we're not necessarily doing a great job at testing the error messages: it's nice to know that FooError has been raised, but if the message is 'Error' it leads to what you're describing, where you need to look at the code and potentially change it to debug it. I believe more consistent tests may help that a bit. Cheers, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Review] Use of exception for non-exceptional cases
On Wed, Jul 10, 2013 at 8:32 PM, Mark McLoughlin mar...@redhat.com wrote: On Wed, 2013-07-10 at 11:01 -0700, Nachi Ueno wrote: Personally, I prefer not to use exception for such cases. The key here is personally. I don't think we have to agree on all style issues. My instinct is the same, but EAFP does seem to be the python way. There are times I can tolerate the EAFP approach but, even then, I generally think LBYL is cleaner. I can live with something like this: try: return obj.foo except AttributeError: pass but this is obviously broken: try: return self.do_something(obj.foo) except AttributeError: pass since AttributeError will mask a typo with the do_something() call or an AttributeError raised from inside do_something() But I fail to see what's wrong with this: if hasattr(obj, 'foo'): return obj.foo hasattr is a bit dangerous as it catches more exceptions than it needs too. See for example http://stackoverflow.com/questions/903130/hasattr-vs-try-except-block-to-deal-with-non-existent-attributes/16186050#16186050for an explanation. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
