On 16/01/14 00:28, Clint Byrum wrote:
> Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800:
>> I'll start by laying out how I see editing or updating nodes working
>> in TripleO without Tuskar:
>>
>> To do my initial deployment:
>> 1. I build a set of images for my deployment for different roles. The
>> images are different based on their role, and only contain the needed
>> software components to accomplish the role they intend to be deployed.
>> 2. I load the images into glance
>> 3. I create the Heat template for my deployment, likely from
>> fragments that are already avaiable. Set quantities, indicate which
>> images (via image uuid) are for which resources in heat.
>> 4. heat stack-create with my template to do the deployment
>>
>> To update my deployment:
>> 1. If I need to edit a role (or create a new one), I create a new image.
>> 2. I load the new image(s) into glance
>> 3. I edit my Heat template, update any quantities, update any image uuids,
>> etc.
>> 4. heat stack-update my deployment
>>
>> In both cases above, I see the role of Tuskar being around steps 3 and 4.
>>
>
> Agreed!
>
+1 ...
review /#/c/52045/ is about generating the overcloud template using
merge.py **. Having recently picked this up again and following latest
wireframes and UI design, it seems like most of current Tuskar code is
going away. After initial panick I saw Jay has actually already started
that with /#/c/66062/
Jay: I think at some point (asap) my /#/c/52045/ will be rebased on your
/#/c/66062/. Currently my code creates templates from the Tuskar
representations, i.e. ResourceClasses. For now I will assume that I'll
be getting something along the lines of:
{
'resource_categories': { 'controller': 1, 'compute': 4, 'object': 1,
'block' 2}
}
i.e. just resource categories and number of instances for each (plus any
other user supplied config/auth info). Will there be controllers (do we
need them, apart from a way to create, update, delete)? Let's talk some
more on irc later. I'll update the commit message on my review to point
to yours for now,
thanks! marios
** merge.py is going to be binned but it is the best thing we've got
_today_ and within the Icehouse timeframe.
> Steps 1 and 2 are really CI's responsibility in a CD cloud. The end of
> the testing phase is "new images in glance!" For a stable release cloud,
> a tool for pulling new released images from elsewhere into Glance would
> be really useful, but worst case an admin downloads the new images and
> loads them manually.
>
>> I may be misinterpreting, but let me say that I don't think Tuskar
>> should be building images. There's been a fair amount of discussion
>> around a Nova native image building service [1][2]. I'm actually not
>> sure what the status/concensus on that is, but maybe longer term,
>> Tuskar might call an API to kick off an image build.
>>
>
> Tuskar should just deploy what it has available. I definitely could
> see value in having an image updating service separate from Tuskar,
> but I think there are many different answers for "how do images arrive
> in Glance?".
>
>> Ok, so given that frame of reference, I'll reply inline:
>>
>> On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies <jason.dob...@redhat.com> wrote:
>>> I'm pulling this particular discussion point out of the Wireframes thread so
>>> it doesn't get lost in the replies.
>>>
>>> = Background =
>>>
>>> It started with my first bulletpoint:
>>>
>>> - When a role is edited, if it has existing nodes deployed with the old
>>> version, are the automatically/immediately updated? If not, how do we
>>> reflect that there's a difference between how the role is currently
>>> configured and the nodes that were previously created from it?
>>
>> I would think Roles need to be versioned, and the deployed version
>> recorded as Heat metadata/attribute. When you make a change to a Role,
>> it's a new version. That way you could easily see what's been
>> deployed, and if there's a newer version of the Role to deploy.
>>
>
> Could Tuskar version the whole deployment, but only when you want to
> "make it so" ? If it gets too granular, it becomes pervasive to try and
> keep track of or to roll back. I think that would work well with a goal
> I've always hoped Tuskar would work toward which would be to mostly just
> maintain deployment as a Heat stack that nests the real stack with the
> parameters realized. With Glance growing Heat template storage capability,
> you could just store these versions in Glance.
>
>>> Replies:
>>
>> I know you quoted the below, but I'll reply here since we're in a new thread.
>>
>>> "I would expect any Role change to be applied immediately. If there is some
>>> change where I want to keep older nodes how they are set up and apply new
>>> settings only to new added nodes, I would create new Role then."
>>
>> -1 to applying immediately.
>>
>> When you edit a Role, it gets a new version. But nodes that are
>> deployed with the older version are not automatically updated.
>>
>>> "We will have to store image metadata in tuskar probably, that would map to
>>> glance, once the image is generated. I would say we need to store the list
>>> of the elements and probably the commit hashes (because elements can
>>> change). Also it should be versioned, as the images in glance will be also
>>> versioned.
>>
>> I'm not sure why this image metadata would be in Tuskar. I definitely
>> like the idea of knowing the versions/commit hashes of the software
>> components in your images, but that should probably be in Glance.
>>
>
> Glance is also growing more capabilities to store metadata and be
> searchable. Tuskar doesn't need to reinvent this any more than Murano
> or Heat do.
>
>>> We can't probably store it in the Glance, cause we will first store the
>>> metadata, then generate image. Right?
>>
>> I'm not sure I follow this point. But, mainly, I don't think Tuskar
>> should be automatically generating images.
>>
>>> Then we could see whether image was created from the metadata and whether
>>> that image was used in the heat-template. With versions we could also see
>>> what has changed.
>>
>> We'll be able to tell what image was used in the heat template, and
>> thus the deployment, based on it's UUID.
>>
>> I love the idea of seeing differences between images, especially
>> installed software versions, but I'm not sure that belongs in Tuskar.
>> That sort of utility functionality seems like it could apply to any
>> image you might want to launch in OpenStack, not just to do a
>> deployment. So, I think it makes sense to have that as Glance
>> metadata or in Glance somehow. For instance, if I wanted to launch an
>> image that had a specific version of apache, it'd be nice to be able
>> to see that when I'm choosing an image to launch.
>>
>>> But there was also idea that there will be some generic image, containing
>>> all services, we would just configure which services to start. In that case
>>> we would need to version also this.
>>
>> -1 to this. I think we should stick with specialized images per role.
>> I replied on the wireframes thread, but I don't see how
>> enabling/disabling services in a prebuilt image should work. Plus, I
>> don't really think it fits with the TripleO model of having an image
>> created based on it's specific "role" (I hate to use that term and
>> muddy the water....i mean in the generic sense here).
>>
>
> A generic image just requires more state management and configuration.
> That seems like a net loss in efficiency, as both of those things move
> failure modes into production instead of keeping them firmly rooted in
> test/dev.
>
> <snip>
>
>>> - For the comment on a generic image with service configuration, the first
>>> thing that came to mind was the thread on creating images from packages [1].
>>> It's not the exact same problem, but see Clint Byrum's comments in there
>>> about drift. My gut feeling is that having specific images for each res-cat
>>> will be easier to manage than trying to edit what services are running on a
>>> node.
>>
>> +1.
>>
>
> Perhaps obviously, +1 as well. :)
>
> _______________________________________________
> 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
