Excerpts from Zane Bitter's message of 2014-04-25 10:05:31 -0700: > On 25/04/14 08:30, Denis Makogon wrote: > > Hello Trove/Heat community. > > > > I'd like to start thread related to required use cases (from Trove > > perspective). To support (completely) Heat in Trove, it neeeds to > > support required operations like: > > > > > > 1. > > > > Resize operations: > > > > - resize a volume (to bigger size); > > This is kind of messy, because it involves operations (i.e. association > with an instance) that are, in theory, expressed independently of the > Volume itself in the template. It should be do-able though. > > > - consistent resize of instance flavor. > > Server resize is implemented already in Heat. I believe what is missing > is a hook to allow Trove to confirm (or not) the resize. Heat always > confirms at the moment. > > http://junodesignsummit.sched.org/event/d422b859492cd1dbcb9763c8b7245f23 >
Right, this is similar to the rebuild case that TripleO needs. I believe software deployments has laid a nice framework down for this, and I'm working right now on a POC for rebuild that will quite easily translate into resize as well. > > 2. > > > > Migration operation (from host to host). > > It's not clear to me how this would fit into Heat's declarative model > (since it's an action, rather than a thing or a relationship between > things). Given that this is presumably an admin-type operation, maybe it > is OK for this to continue to be done with the Nova client. > Assuming you mean nova migration, which is an administrative action in Nova, I agree with Zane, except that I wouldn't say maybe, but "most likely". However, the statement is a bit vague, so you could mean _trove_ host to _trove_ host. As in, migrating a whole database and then a VIP to another database. I think there is a role for Heat to play there, as you would change your desired end-goal to have two servers, and even use Heat to communicate the details how the migration path to the new one, and then change the goal again to just have the new server, with the VIP moved. > > 3. > > > > Security group/rules operations: > > > > - add new rules to already existing group; > > > > - swap existing rules to a new ones. > > This appears to be implemented already (for Neutron security groups), > though the implementation looks a bit suspect to me: > > https://github.com/openstack/heat/blob/master/heat/engine/resources/neutron/security_group.py#L237 > > > 4. > > > > Designate (DNSaaS) resource provisioning. > > +1! If someone wanted to write this we would be more than happy to see > it in /contrib right now, and moving to the main tree as soon as > Designate is accepted for incubation. > Agreed. DNS all the things. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
