Open Stack

On Fri, Apr 25, 2014 at 8:44 PM, Clint Byrum <clint at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/5fa8758e/attachment.html>