Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-23 Thread Flavio Percoco 

On 12/01/17 08:11 -0500, Zane Bitter wrote:

On 11/01/17 10:01, Thomas Herve wrote:

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:

On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.


If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.


Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.


For those following along at home, this merged: 
https://review.openstack.org/#/c/418987/


Patch to deprecate the resource type: 
https://review.openstack.org/#/c/419043/


Thanks for the work here, folks!
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-12 Thread Zane Bitter 

On 11/01/17 10:01, Thomas Herve wrote:

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:

On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.


If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.


Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.


For those following along at home, this merged: 
https://review.openstack.org/#/c/418987/


Patch to deprecate the resource type: 
https://review.openstack.org/#/c/419043/


- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-12 Thread Flavio Percoco 

On 11/01/17 16:01 +0100, Thomas Herve wrote:

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:

On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.


If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.


Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.


Thanks, Thomas!

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-11 Thread Clint Byrum 
Excerpts from Thomas Herve's message of 2017-01-11 08:50:19 +0100:
> On Tue, Jan 10, 2017 at 10:41 PM, Clint Byrum  wrote:
> > Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500:
> >> location is a required property:
> >>
> >> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
> >>
> >> The resource type literally does not do anything else but expose a Heat
> >> interface to a feature of Glance that no longer exists in v2. That's
> >> fundamentally why "add v2 support" has been stalled for so long ;)
> >>
> >
> > I think most of this has been beating around the bush, and the statement
> > above is the heart of the issue.
> >
> > The functionality was restricted and mostly removed from Glance for a
> > reason. Heat users will have to face that reality just like users of
> > other orchestration systems have to.
> >
> > If a cloud has v1.. great.. take a location.. use it. If they have v2..
> > location explodes. If you want to get content in to that image, well,
> > other systems have to deal with this too. Ansible's os_image will upload
> > a local file to glance for instance. Terraform doesn't even include
> > image support.
> >
> > So the way to go is likely to just make location optional, and start
> > to use v2 when the catalog says to. From there, Heat can probably help
> > make the v2 API better, and perhaps add support to to the Heat API to
> > tell the user where they can upload blobs of data for Heat to then feed
> > into Glance.
> 
> Making location optional doesn't really make sense. We don't have any
> mechanism in a template to upload data, so it would just create an
> empty shell that you can't use to boot instances from.
> 
> I think this is going where I thought it would: let's not do anything.
> The image resource is there for v1 compatibility, but there is no
> point to have a v2 resource, at least right now.

Agreed, not much point w/o upload facilities.

So what about adding that to Heat's API? A way to tell the user "in
order to create your stack I'll need you to upload these data blobs"
would also be generically useful for any large data blob that resources
would want, such as swift files.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-11 Thread Thomas Herve 
On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:
> On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:
>> I think this is going where I thought it would: let's not do anything.
>> The image resource is there for v1 compatibility, but there is no
>> point to have a v2 resource, at least right now.
>
> If we do nothing, we force our heat-template users to keep Glance v1
> API enabled in their cloud (+ running Glance Registry service), which
> at some point doens't make sense, since Glance team asked to moved
> forward with Glance v2 API.
>
> I would really recommend to move forward and stop ignoring the new API 
> version.

Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.

-- 
Thomas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-11 Thread Emilien Macchi 
On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:
> On Tue, Jan 10, 2017 at 10:41 PM, Clint Byrum  wrote:
>> Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500:
>>> location is a required property:
>>>
>>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
>>>
>>> The resource type literally does not do anything else but expose a Heat
>>> interface to a feature of Glance that no longer exists in v2. That's
>>> fundamentally why "add v2 support" has been stalled for so long ;)
>>>
>>
>> I think most of this has been beating around the bush, and the statement
>> above is the heart of the issue.
>>
>> The functionality was restricted and mostly removed from Glance for a
>> reason. Heat users will have to face that reality just like users of
>> other orchestration systems have to.
>>
>> If a cloud has v1.. great.. take a location.. use it. If they have v2..
>> location explodes. If you want to get content in to that image, well,
>> other systems have to deal with this too. Ansible's os_image will upload
>> a local file to glance for instance. Terraform doesn't even include
>> image support.
>>
>> So the way to go is likely to just make location optional, and start
>> to use v2 when the catalog says to. From there, Heat can probably help
>> make the v2 API better, and perhaps add support to to the Heat API to
>> tell the user where they can upload blobs of data for Heat to then feed
>> into Glance.
>
> Making location optional doesn't really make sense. We don't have any
> mechanism in a template to upload data, so it would just create an
> empty shell that you can't use to boot instances from.
>
> I think this is going where I thought it would: let's not do anything.
> The image resource is there for v1 compatibility, but there is no
> point to have a v2 resource, at least right now.

If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.

> We could document how to hide the resource in Heat if you don't deploy
> Glance v1.
>
> --
> Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Thomas Herve 
On Tue, Jan 10, 2017 at 10:41 PM, Clint Byrum  wrote:
> Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500:
>> location is a required property:
>>
>> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
>>
>> The resource type literally does not do anything else but expose a Heat
>> interface to a feature of Glance that no longer exists in v2. That's
>> fundamentally why "add v2 support" has been stalled for so long ;)
>>
>
> I think most of this has been beating around the bush, and the statement
> above is the heart of the issue.
>
> The functionality was restricted and mostly removed from Glance for a
> reason. Heat users will have to face that reality just like users of
> other orchestration systems have to.
>
> If a cloud has v1.. great.. take a location.. use it. If they have v2..
> location explodes. If you want to get content in to that image, well,
> other systems have to deal with this too. Ansible's os_image will upload
> a local file to glance for instance. Terraform doesn't even include
> image support.
>
> So the way to go is likely to just make location optional, and start
> to use v2 when the catalog says to. From there, Heat can probably help
> make the v2 API better, and perhaps add support to to the Heat API to
> tell the user where they can upload blobs of data for Heat to then feed
> into Glance.

Making location optional doesn't really make sense. We don't have any
mechanism in a template to upload data, so it would just create an
empty shell that you can't use to boot instances from.

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.

We could document how to hide the resource in Heat if you don't deploy
Glance v1.

-- 
Thomas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Clint Byrum 
Excerpts from Thomas Herve's message of 2017-01-10 22:15:45 +0100:
> On Tue, Jan 10, 2017 at 9:28 PM, Zane Bitter  wrote:
> > On 10/01/17 14:17, Tim Bell wrote:
> >>
> >>
> >>> On 10 Jan 2017, at 17:41, Zane Bitter  >>> > wrote:
> >>>
> >>> On 10/01/17 05:25, Flavio Percoco wrote:
> 
> 
> 
> > I'd recommend Heat to not use locations as that will require deployers
> > to either enable them for everyone or have a dedicate glance-api node
> > for Heat.
> > If not use location, do we have other options for user? What
> > should user to do before create a glance image using v2? Download the
> > image data? And then pass the image data to glance api? I really don't
> > think it's good way.
> >
> 
>  That *IS* how users create images. There used to be copy-from too (which
>  may or
>  may not come back).
> 
>  Heat's use case is different and I understand that but as I said in my
>  other
>  email, I do not think sticking to v1 is the right approach. I'd rather
>  move on
>  with a deprecation path or compatibility layer.
> >>>
> >>>
> >>> "Backwards-compatibility" is a wide-ranging topic, so let's break this
> >>> down into 3 more specific questions:
> >>>
> >>> 1) What is an interface that we could support with the v2 API?
> >>>
> >>> - If copy-from is not a thing then it sounds to me like the answer is
> >>> "none"? We are not ever going to support uploading a multi-GB image
> >>> file through Heat and from there to Glance.
> >>> - We could have an Image resource that creates a Glance image from a
> >>> volume. It's debatable how useful this would be in an orchestration
> >>> setting (i.e. in most cases this would have to be part of a larger
> >>> workflow anyway), but there are some conceivable uses I guess. Given
> >>> that this is completely disjoint from what the current resource type
> >>> does, we'd make it easier on everyone if we just gave it a new name.
> >>>
> >>> 2) How can we avoid breaking existing stacks that use Image resources?
> >>>
> >>> - If we're not replacing it with anything, then we can just mark the
> >>> resource type as first Deprecated, and then Hidden and switch the back
> >>> end to use the v2 API for things like deleting. As long as nobody
> >>> attempts to replace the image then the rest of the stack should
> >>> continue to work fine.
> >>>
> >>
> >> Can we only deprecate the resources using the location function but
> >> maintain backwards compatibility if the location function is not used?
> >
> >
> > location is a required property:
> >
> > http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
> >
> > The resource type literally does not do anything else but expose a Heat
> > interface to a feature of Glance that no longer exists in v2. That's
> > fundamentally why "add v2 support" has been stalled for so long ;)
> 
> Throwing stuff against the wall, but could we solve the issue in
> heatclient? If we change it to handle the location property, upload
> the image from the client, and pass the id to Heat, it could be
> somewhat transparent to the user. We'd need to do it in Horizon
> though. For the heatclient as a library it's not perfect, but it may
> be good enough.
> 

Pretend that python doesn't exist outside the API layer of a running
service.

The REST API has to do something sane. So IMO, the Heat API's stack
create/update methods need to start feeding back instructions on where
and how to upload data.

But the simple answer is, right now, you just have to create images
outside of stacks.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Clint Byrum 
Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500:
> On 10/01/17 14:17, Tim Bell wrote:
> >
> >> On 10 Jan 2017, at 17:41, Zane Bitter  >> > wrote:
> >>
> >> On 10/01/17 05:25, Flavio Percoco wrote:
> >>>
> >>>
>  I'd recommend Heat to not use locations as that will require deployers
>  to either enable them for everyone or have a dedicate glance-api node
>  for Heat.
>  If not use location, do we have other options for user? What
>  should user to do before create a glance image using v2? Download the
>  image data? And then pass the image data to glance api? I really don't
>  think it's good way.
> 
> >>>
> >>> That *IS* how users create images. There used to be copy-from too (which
> >>> may or
> >>> may not come back).
> >>>
> >>> Heat's use case is different and I understand that but as I said in my
> >>> other
> >>> email, I do not think sticking to v1 is the right approach. I'd rather
> >>> move on
> >>> with a deprecation path or compatibility layer.
> >>
> >> "Backwards-compatibility" is a wide-ranging topic, so let's break this
> >> down into 3 more specific questions:
> >>
> >> 1) What is an interface that we could support with the v2 API?
> >>
> >> - If copy-from is not a thing then it sounds to me like the answer is
> >> "none"? We are not ever going to support uploading a multi-GB image
> >> file through Heat and from there to Glance.
> >> - We could have an Image resource that creates a Glance image from a
> >> volume. It's debatable how useful this would be in an orchestration
> >> setting (i.e. in most cases this would have to be part of a larger
> >> workflow anyway), but there are some conceivable uses I guess. Given
> >> that this is completely disjoint from what the current resource type
> >> does, we'd make it easier on everyone if we just gave it a new name.
> >>
> >> 2) How can we avoid breaking existing stacks that use Image resources?
> >>
> >> - If we're not replacing it with anything, then we can just mark the
> >> resource type as first Deprecated, and then Hidden and switch the back
> >> end to use the v2 API for things like deleting. As long as nobody
> >> attempts to replace the image then the rest of the stack should
> >> continue to work fine.
> >>
> >
> > Can we only deprecate the resources using the location function but
> > maintain backwards compatibility if the location function is not used?
> 
> location is a required property:
> 
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
> 
> The resource type literally does not do anything else but expose a Heat 
> interface to a feature of Glance that no longer exists in v2. That's 
> fundamentally why "add v2 support" has been stalled for so long ;)
> 

I think most of this has been beating around the bush, and the statement
above is the heart of the issue.

The functionality was restricted and mostly removed from Glance for a
reason. Heat users will have to face that reality just like users of
other orchestration systems have to.

If a cloud has v1.. great.. take a location.. use it. If they have v2..
location explodes. If you want to get content in to that image, well,
other systems have to deal with this too. Ansible's os_image will upload
a local file to glance for instance. Terraform doesn't even include
image support.

So the way to go is likely to just make location optional, and start
to use v2 when the catalog says to. From there, Heat can probably help
make the v2 API better, and perhaps add support to to the Heat API to
tell the user where they can upload blobs of data for Heat to then feed
into Glance.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Thomas Herve 
On Tue, Jan 10, 2017 at 9:28 PM, Zane Bitter  wrote:
> On 10/01/17 14:17, Tim Bell wrote:
>>
>>
>>> On 10 Jan 2017, at 17:41, Zane Bitter >> > wrote:
>>>
>>> On 10/01/17 05:25, Flavio Percoco wrote:



> I'd recommend Heat to not use locations as that will require deployers
> to either enable them for everyone or have a dedicate glance-api node
> for Heat.
> If not use location, do we have other options for user? What
> should user to do before create a glance image using v2? Download the
> image data? And then pass the image data to glance api? I really don't
> think it's good way.
>

 That *IS* how users create images. There used to be copy-from too (which
 may or
 may not come back).

 Heat's use case is different and I understand that but as I said in my
 other
 email, I do not think sticking to v1 is the right approach. I'd rather
 move on
 with a deprecation path or compatibility layer.
>>>
>>>
>>> "Backwards-compatibility" is a wide-ranging topic, so let's break this
>>> down into 3 more specific questions:
>>>
>>> 1) What is an interface that we could support with the v2 API?
>>>
>>> - If copy-from is not a thing then it sounds to me like the answer is
>>> "none"? We are not ever going to support uploading a multi-GB image
>>> file through Heat and from there to Glance.
>>> - We could have an Image resource that creates a Glance image from a
>>> volume. It's debatable how useful this would be in an orchestration
>>> setting (i.e. in most cases this would have to be part of a larger
>>> workflow anyway), but there are some conceivable uses I guess. Given
>>> that this is completely disjoint from what the current resource type
>>> does, we'd make it easier on everyone if we just gave it a new name.
>>>
>>> 2) How can we avoid breaking existing stacks that use Image resources?
>>>
>>> - If we're not replacing it with anything, then we can just mark the
>>> resource type as first Deprecated, and then Hidden and switch the back
>>> end to use the v2 API for things like deleting. As long as nobody
>>> attempts to replace the image then the rest of the stack should
>>> continue to work fine.
>>>
>>
>> Can we only deprecate the resources using the location function but
>> maintain backwards compatibility if the location function is not used?
>
>
> location is a required property:
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image
>
> The resource type literally does not do anything else but expose a Heat
> interface to a feature of Glance that no longer exists in v2. That's
> fundamentally why "add v2 support" has been stalled for so long ;)

Throwing stuff against the wall, but could we solve the issue in
heatclient? If we change it to handle the location property, upload
the image from the client, and pass the id to Heat, it could be
somewhat transparent to the user. We'd need to do it in Horizon
though. For the heatclient as a library it's not perfect, but it may
be good enough.

-- 
Thomas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Zane Bitter 

On 10/01/17 14:17, Tim Bell wrote:



On 10 Jan 2017, at 17:41, Zane Bitter > wrote:

On 10/01/17 05:25, Flavio Percoco wrote:




I'd recommend Heat to not use locations as that will require deployers
to either enable them for everyone or have a dedicate glance-api node
for Heat.
If not use location, do we have other options for user? What
should user to do before create a glance image using v2? Download the
image data? And then pass the image data to glance api? I really don't
think it's good way.



That *IS* how users create images. There used to be copy-from too (which
may or
may not come back).

Heat's use case is different and I understand that but as I said in my
other
email, I do not think sticking to v1 is the right approach. I'd rather
move on
with a deprecation path or compatibility layer.


"Backwards-compatibility" is a wide-ranging topic, so let's break this
down into 3 more specific questions:

1) What is an interface that we could support with the v2 API?

- If copy-from is not a thing then it sounds to me like the answer is
"none"? We are not ever going to support uploading a multi-GB image
file through Heat and from there to Glance.
- We could have an Image resource that creates a Glance image from a
volume. It's debatable how useful this would be in an orchestration
setting (i.e. in most cases this would have to be part of a larger
workflow anyway), but there are some conceivable uses I guess. Given
that this is completely disjoint from what the current resource type
does, we'd make it easier on everyone if we just gave it a new name.

2) How can we avoid breaking existing stacks that use Image resources?

- If we're not replacing it with anything, then we can just mark the
resource type as first Deprecated, and then Hidden and switch the back
end to use the v2 API for things like deleting. As long as nobody
attempts to replace the image then the rest of the stack should
continue to work fine.



Can we only deprecate the resources using the location function but
maintain backwards compatibility if the location function is not used?


location is a required property:

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image

The resource type literally does not do anything else but expose a Heat 
interface to a feature of Glance that no longer exists in v2. That's 
fundamentally why "add v2 support" has been stalled for so long ;)



3) How do we handle existing templates in future?

- Again, if we're not replacing it with anything, the -> Deprecated ->
Hidden process is sufficient. (In theory "Hidden" should mean you
can't create new stacks containing that resource type any more, only
continue using existing stacks that contained it. In practice, we
didn't actually implement that and it just gets hidden from the
documentation. Obviously trying to create a new one using the location
field once only the v2 API is available will result in an error.)



My worry is that portable heat templates like the Community App Catalog
( http://apps.openstack.org/#tab=heat-templates) would become much more
complex if we have to produce different resources for Glance V1 and V2
configurations. If, however, we are able to say that the following
definitions of image resources are compatible across the two
configurations, this can be more supportive of a catalog approach and
improve template portability.


Are any of those templates actually using OS::Glance::Image resources 
though? (I'd check myself but I can't find the source repo - 
openstack/app-catalog appears to contain just the catalog and not any of 
the apps?)


cheers,
Zane.


Tim



If we have a different answer to (1) then that could change the
answers to (2) and (3).

cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Tim Bell 

On 10 Jan 2017, at 17:41, Zane Bitter 
> wrote:

On 10/01/17 05:25, Flavio Percoco wrote:


I'd recommend Heat to not use locations as that will require deployers
to either enable them for everyone or have a dedicate glance-api node
for Heat.
If not use location, do we have other options for user? What
should user to do before create a glance image using v2? Download the
image data? And then pass the image data to glance api? I really don't
think it's good way.


That *IS* how users create images. There used to be copy-from too (which
may or
may not come back).

Heat's use case is different and I understand that but as I said in my
other
email, I do not think sticking to v1 is the right approach. I'd rather
move on
with a deprecation path or compatibility layer.

"Backwards-compatibility" is a wide-ranging topic, so let's break this down 
into 3 more specific questions:

1) What is an interface that we could support with the v2 API?

- If copy-from is not a thing then it sounds to me like the answer is "none"? 
We are not ever going to support uploading a multi-GB image file through Heat 
and from there to Glance.
- We could have an Image resource that creates a Glance image from a volume. 
It's debatable how useful this would be in an orchestration setting (i.e. in 
most cases this would have to be part of a larger workflow anyway), but there 
are some conceivable uses I guess. Given that this is completely disjoint from 
what the current resource type does, we'd make it easier on everyone if we just 
gave it a new name.

2) How can we avoid breaking existing stacks that use Image resources?

- If we're not replacing it with anything, then we can just mark the resource 
type as first Deprecated, and then Hidden and switch the back end to use the v2 
API for things like deleting. As long as nobody attempts to replace the image 
then the rest of the stack should continue to work fine.


Can we only deprecate the resources using the location function but maintain 
backwards compatibility if the location function is not used?

3) How do we handle existing templates in future?

- Again, if we're not replacing it with anything, the -> Deprecated -> Hidden 
process is sufficient. (In theory "Hidden" should mean you can't create new 
stacks containing that resource type any more, only continue using existing 
stacks that contained it. In practice, we didn't actually implement that and it 
just gets hidden from the documentation. Obviously trying to create a new one 
using the location field once only the v2 API is available will result in an 
error.)


My worry is that portable heat templates like the Community App Catalog ( 
http://apps.openstack.org/#tab=heat-templates) would become much more complex 
if we have to produce different resources for Glance V1 and V2 configurations. 
If, however, we are able to say that the following definitions of image 
resources are compatible across the two configurations, this can be more 
supportive of a catalog approach and improve template portability.

Tim


If we have a different answer to (1) then that could change the answers to (2) 
and (3).

cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Zane Bitter 

On 10/01/17 05:25, Flavio Percoco wrote:




I'd recommend Heat to not use locations as that will require deployers
to either enable them for everyone or have a dedicate glance-api node
for Heat.
If not use location, do we have other options for user? What
should user to do before create a glance image using v2? Download the
image data? And then pass the image data to glance api? I really don't
think it's good way.



That *IS* how users create images. There used to be copy-from too (which
may or
may not come back).

Heat's use case is different and I understand that but as I said in my
other
email, I do not think sticking to v1 is the right approach. I'd rather
move on
with a deprecation path or compatibility layer.


"Backwards-compatibility" is a wide-ranging topic, so let's break this 
down into 3 more specific questions:


1) What is an interface that we could support with the v2 API?

- If copy-from is not a thing then it sounds to me like the answer is 
"none"? We are not ever going to support uploading a multi-GB image file 
through Heat and from there to Glance.
- We could have an Image resource that creates a Glance image from a 
volume. It's debatable how useful this would be in an orchestration 
setting (i.e. in most cases this would have to be part of a larger 
workflow anyway), but there are some conceivable uses I guess. Given 
that this is completely disjoint from what the current resource type 
does, we'd make it easier on everyone if we just gave it a new name.


2) How can we avoid breaking existing stacks that use Image resources?

- If we're not replacing it with anything, then we can just mark the 
resource type as first Deprecated, and then Hidden and switch the back 
end to use the v2 API for things like deleting. As long as nobody 
attempts to replace the image then the rest of the stack should continue 
to work fine.


3) How do we handle existing templates in future?

- Again, if we're not replacing it with anything, the -> Deprecated -> 
Hidden process is sufficient. (In theory "Hidden" should mean you can't 
create new stacks containing that resource type any more, only continue 
using existing stacks that contained it. In practice, we didn't actually 
implement that and it just gets hidden from the documentation. Obviously 
trying to create a new one using the location field once only the v2 API 
is available will result in an error.)



If we have a different answer to (1) then that could change the answers 
to (2) and (3).


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Flavio Percoco 

On 10/01/17 08:59 +, Huangtianhua wrote:



-邮件原件-
发件人: Flavio Percoco [mailto:fla...@redhat.com]
发送时间: 2017年1月10日 15:34
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [heat] glance v2 support?

On 10/01/17 12:35 +0530, Rabi Mishra wrote:

On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco  wrote:


On 06/01/17 09:34 +0530, Rabi Mishra wrote:


On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi 
wrote:

Greetings Heat folks!


My question is simple:
When do you plan to support Glance v2?
https://review.openstack.org/#/c/240450/

The spec looks staled while Glance v1 was deprecated in Newton (and
v2 was started in Kilo!).


Hi Emilien,


I think we've not been able to move to v2 due to v1/v2
incompatibility[1] with respect to the location[2] property. Moving
to v2 would break all existing templates using that property.

I've seen several discussions around that without any conclusion.  I
think we can support a separate v2 image resource and deprecate the
current one, unless there is a better path available.



Hi Rabi,

Could you elaborate on why Heat depends on the location attribute?
I'm not familiar with Heat and knowing this might help me to propose
something (or at least understand the difficulties).

I don't think putting this on hold will be of any help. V1 ain't
coming back and the improvements for v2 are still under heavy coding.
I'd probably recommend moving to v2 with a proper deprecation path
rather than sticking to v1.



Hi Flavio,

As much as we would like to move to v2, I think we still don't have a
acceptable solution for the question below. There is an earlier ML
thread[1], where it was discussed in detail.

- What's the migration path for images created with v1 that use the
location attribute pointing to an external location?


Moving to Glance v2 shouldn't break this. As in, Glance will still be able to 
pull the images from external locations.

Also, to be precise more precise, you actually *can* use locations in V2.
Glance's node needs to have 2 settings enabled. The first is 
`show_multple_locations` and the second one is a policy config[0]. It's however 
not recommended to expose that to end users but that's why it was shielded 
behind policies.
---As you said, we can't use location in v2 by default. IMO, If glance v2 is 
compatible with v1, the option should be enabled by default.



I don't think this will happen. It's no news, tbh. The Glance community has been
comunicating this since the Kilo release. It was written in different times,
under different assumptions and the price is still being paid.


I'd recommend Heat to not use locations as that will require deployers to 
either enable them for everyone or have a dedicate glance-api node for Heat.
If not use location, do we have other options for user? What should user to 
do before create a glance image using v2? Download the image data? And then 
pass the image data to glance api? I really don't think it's good way.



That *IS* how users create images. There used to be copy-from too (which may or
may not come back).

Heat's use case is different and I understand that but as I said in my other
email, I do not think sticking to v1 is the right approach. I'd rather move on
with a deprecation path or compatibility layer.


Flavio


All that being said, switching to v2 won't prevent Glance from reading images 
from external locations if the image records exist already.
Yes, but how to create a new glance image?

[0] https://github.com/openstack/glance/blob/master/etc/policy.json#L16-L18


While answering the above we've to keep in mind the following constraint.

- Any change in the image id(new image) would potentially result in
nova servers using them in the template being rebuilt/replaced, and we
would like to avoid it.

There was a suggestion to allow the 'copy-from'  with v2, which would
possibly make it easier for us. Is that still an option?


May be, in the long future. The improvements for v2 are still under heavy 
development.


I assume we can probably use glance upload api to upload the image
data(after getting it from the external location) for an existing image?
Last time i tried to do it, it seems to be not allowed for an 'active'
image. It's  possible I'm missing something here.  We don't have a way
at present,  for a user to upload an image to heat engine( not sure if
we would like do to it either) or heat engine downloading the image
from an 'external location' and then uploading it to glance while
creating/updating an image resource.


Downloading the image locally and uploading it is a workaround, yes. Not ideal 
but it's simple. However, you won't need it for the migration to v2, I believe, 
since you can re-use existing images. Heat won't be able to create new images 
and have them point to external locations, though, unless the settings I 
mentioned above have been enabled.


Also, glance location api could

[openstack-dev] 答复: [heat] glance v2 support?

2017-01-10 Thread Huangtianhua 


-邮件原件-
发件人: Flavio Percoco [mailto:fla...@redhat.com] 
发送时间: 2017年1月10日 15:34
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [heat] glance v2 support?

On 10/01/17 12:35 +0530, Rabi Mishra wrote:
>On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco  wrote:
>
>> On 06/01/17 09:34 +0530, Rabi Mishra wrote:
>>
>>> On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi 
>>> wrote:
>>>
>>> Greetings Heat folks!

 My question is simple:
 When do you plan to support Glance v2?
 https://review.openstack.org/#/c/240450/

 The spec looks staled while Glance v1 was deprecated in Newton (and 
 v2 was started in Kilo!).


 Hi Emilien,
>>>
>>> I think we've not been able to move to v2 due to v1/v2 
>>> incompatibility[1] with respect to the location[2] property. Moving 
>>> to v2 would break all existing templates using that property.
>>>
>>> I've seen several discussions around that without any conclusion.  I 
>>> think we can support a separate v2 image resource and deprecate the 
>>> current one, unless there is a better path available.
>>>
>>
>> Hi Rabi,
>>
>> Could you elaborate on why Heat depends on the location attribute? 
>> I'm not familiar with Heat and knowing this might help me to propose 
>> something (or at least understand the difficulties).
>>
>> I don't think putting this on hold will be of any help. V1 ain't 
>> coming back and the improvements for v2 are still under heavy coding. 
>> I'd probably recommend moving to v2 with a proper deprecation path 
>> rather than sticking to v1.
>>
>>
>Hi Flavio,
>
>As much as we would like to move to v2, I think we still don't have a 
>acceptable solution for the question below. There is an earlier ML 
>thread[1], where it was discussed in detail.
>
>- What's the migration path for images created with v1 that use the 
>location attribute pointing to an external location?

Moving to Glance v2 shouldn't break this. As in, Glance will still be able to 
pull the images from external locations.

Also, to be precise more precise, you actually *can* use locations in V2.
Glance's node needs to have 2 settings enabled. The first is 
`show_multple_locations` and the second one is a policy config[0]. It's however 
not recommended to expose that to end users but that's why it was shielded 
behind policies.
---As you said, we can't use location in v2 by default. IMO, If glance v2 is 
compatible with v1, the option should be enabled by default.

I'd recommend Heat to not use locations as that will require deployers to 
either enable them for everyone or have a dedicate glance-api node for Heat.
If not use location, do we have other options for user? What should user to 
do before create a glance image using v2? Download the image data? And then 
pass the image data to glance api? I really don't think it's good way.

All that being said, switching to v2 won't prevent Glance from reading images 
from external locations if the image records exist already.
Yes, but how to create a new glance image?

[0] https://github.com/openstack/glance/blob/master/etc/policy.json#L16-L18

>While answering the above we've to keep in mind the following constraint.
>
>- Any change in the image id(new image) would potentially result in 
>nova servers using them in the template being rebuilt/replaced, and we 
>would like to avoid it.
>
>There was a suggestion to allow the 'copy-from'  with v2, which would 
>possibly make it easier for us. Is that still an option?

May be, in the long future. The improvements for v2 are still under heavy 
development.

>I assume we can probably use glance upload api to upload the image 
>data(after getting it from the external location) for an existing image?
>Last time i tried to do it, it seems to be not allowed for an 'active'
>image. It's  possible I'm missing something here.  We don't have a way 
>at present,  for a user to upload an image to heat engine( not sure if 
>we would like do to it either) or heat engine downloading the image 
>from an 'external location' and then uploading it to glance while 
>creating/updating an image resource.

Downloading the image locally and uploading it is a workaround, yes. Not ideal 
but it's simple. However, you won't need it for the migration to v2, I believe, 
since you can re-use existing images. Heat won't be able to create new images 
and have them point to external locations, though, unless the settings I 
mentioned above have been enabled.

>Also, glance location api could probably have been useful here. 
>However, we were advised in the earlier thread not to use it, as 
>exposing the location to the end user is perceived as a security risk.

++

Flavio

>
>[1]  
>http://lists.openstack.org/pipermail/openstack-dev/2016-May/094598.html
>
>
>Cheers,
>> Flavio
>>
>>
>>> [1] 
>>> https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability
>>> [2]