[openstack-dev] [Trove][Heat] Use cases required for Trove
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); - consistent resize of instance flavor. 2. Migration operation (from host to host). 3. Security group/rules operations: - add new rules to already existing group; - swap existing rules to a new ones. 4. Designate (DNSaaS) resource provisioning. Current Trove master branch code is not ready to fully support all cases proposed. implementation you can find at : https://github.com/denismakogon/trove/tree/bp/resource-management-driver I'd like to envolve Heat community to help Trove community to migrate from use of native clients like novaclient, cinderclient, neutronclient, designateclient to heatclient as single point of resource management. Some of the blueprints are already filed and (some of them) already discussed with the community and some of them are not (yet). So, i'd like to clarify the which use cases already coverd and which are not. Appreciate any response. Also, i'd like to propose cross-project discussion about this topic out of ATL Summit schedule. Here some useful links: * Trove blueprints* https://blueprints.launchpad.net/trove/+spec/resource-management-driver * Heat related blueprints* https://blueprints.launchpad.net/heat/+spec/handle-update-for-security-groups https://blueprints.launchpad.net/heat/+spec/update-cinder-volume Best regards, Denis Makogon dmako...@mirantis.com www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove][Heat] Use cases required for Trove
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
Re: [openstack-dev] [Trove][Heat] Use cases required for Trove
On Fri, Apr 25, 2014 at 8:44 PM, Clint Byrum cl...@fewbar.com wrote: 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. Agreed. But as for me, this use case is the last of the list that's not fully covered in Heat. Only VomuleAttached class has handle_update task, but missing for base Volume class. Last question, can volume update blueprint be approved or needs to be discussed with all Heat community? - 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. From the Trove perspective, the best use case is the case when Heat handles most of the logic over the resize and its confirmation. My best guess that Trove needs to do only stack update procedure, and nothing else. 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. Agreed, migrations will still be the part of the responsibilities of Nova. 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 For now Trove cannot work with Neutron as network management service. So, mostly insterested in nova-network based flow. But for the future we'll also would need Neutron based flow. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
