Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On 09/15/2014 05:33 PM, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2014-09-15 09:31:33 -0700: On 14/09/14 11:09, Clint Byrum wrote: Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. Standard Library implies that everyone has it available, but in reality operators can (and will, and do) deploy any combination of resource types that they want. Mmk, I guess I was being too optimistic about how homogeneous OpenStack clouds might be. (From Zane's other message) snip I think the first supported release is probably the right information to add. snip I feel like for anything with nonzero upgrade effort (and upgrading your openstack install takes significantly more than 0 effort units) you can never assume everyone is running the latest (or even a recent) revision. That's why projects often host docs versions *way* back. The SQLAlchemy project hosts docs back to 2012[1] and also has latest[2] docs that are updated continuously. I think the way to support the most use cases would be to have docs for each release as well as continue to have CI update docs. For a URL structure I could see docs.o.o/developer/heat/latest and d.o.o/heat/VER where VER can be either a semver release (2014.2, etc) or a release name (icehouse, havana, etc). The strategy SQLA and other projects use is to feature a release date prominently at the top of the page, so users can look and say Oh, Juno isn't released yet, so this feature won't be in my Icehouse cloud. [1] http://docs.sqlalchemy.org/en/rel_0_6/core/index.html [2] http://docs.sqlalchemy.org/en/latest/core/index.html The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. We already have API calls to actually inspect resource types. I don't think a semantic version number is helpful here, since the different existing combinations of resources types are not expressible linearly. There's no really good answer here, but the only real answer is making sure it's easy for people to generate the docs themselves for their actual deployment. That's an interesting idea. By any chance do we have something that publishes the docs directly from source tree into swift? Might make it easier if we could just do that as part of code pushes for those who run clouds from source. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Maybe continuous deployers should continuously deploy their own docs? For any given cloud the only thing that matters is what it supports right now. Thats an interesting idea, but I like what the user wants is to see how this cloud is different than the other clouds. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. The original question was about docs.openstack.org, and in that context I think tying it to the release version is a good choice, because that's... how OpenStack is released. Individual clouds, however, really need to deploy their own docs that document what they actually support. Yeah I hadn't thought of that before. I like the idea but I wonder how practical it is for CD private clouds. The flip side of this, of course, is that whatever we use for the version strings on docs.openstack.org will all make its way
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On 09/16/2014 09:49 AM, Ryan Brown wrote:. (From Zane's other message) snip I think the first supported release is probably the right information to add. snip I feel like for anything with nonzero upgrade effort (and upgrading your openstack install takes significantly more than 0 effort units) you can never assume everyone is running the latest (or even a recent) revision. That's why projects often host docs versions *way* back. The SQLAlchemy project hosts docs back to 2012[1] and also has latest[2] docs that are updated continuously. I think the way to support the most use cases would be to have docs for each release as well as continue to have CI update docs. For a URL structure I could see docs.o.o/developer/heat/latest and d.o.o/heat/VER where VER can be either a semver release (2014.2, etc) or a release name (icehouse, havana, etc). The strategy SQLA and other projects use is to feature a release date prominently at the top of the page, so users can look and say Oh, Juno isn't released yet, so this feature won't be in my Icehouse cloud. [1] http://docs.sqlalchemy.org/en/rel_0_6/core/index.html [2] http://docs.sqlalchemy.org/en/latest/core/index.html Also most projects that use readthedocs.org have a dropdown on every docs page that link to that page at different releases. I think it would greatly improve discoverability of documentation for prior releases. Sorry for doubling up messages, -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On 14/09/14 11:09, Clint Byrum wrote: Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. Standard Library implies that everyone has it available, but in reality operators can (and will, and do) deploy any combination of resource types that they want. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. We already have API calls to actually inspect resource types. I don't think a semantic version number is helpful here, since the different existing combinations of resources types are not expressible linearly. There's no really good answer here, but the only real answer is making sure it's easy for people to generate the docs themselves for their actual deployment. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Maybe continuous deployers should continuously deploy their own docs? For any given cloud the only thing that matters is what it supports right now. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. The original question was about docs.openstack.org, and in that context I think tying it to the release version is a good choice, because that's... how OpenStack is released. Individual clouds, however, really need to deploy their own docs that document what they actually support. The flip side of this, of course, is that whatever we use for the version strings on docs.openstack.org will all make its way into all the other documentation that gets built, and I do understand your point in that context. But versioning the standard library of plugins as if it were a monolithic, always-available thing seems wrong to me. We do the same thing with HOT's internals, so why not also do the standard library this way? The current process for HOT is for every OpenStack development cycle (Juno is the first to use this) to give it a 'version' string that is the expected date of the next release (in the future), and continuous deployers who use the new one before that date are on their own (i.e. it's not considered stable). So not really comparable. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On Mon, Sep 15, 2014 at 11:31 AM, Zane Bitter zbit...@redhat.com wrote: On 14/09/14 11:09, Clint Byrum wrote: Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. Standard Library implies that everyone has it available, but in reality operators can (and will, and do) deploy any combination of resource types that they want. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. We already have API calls to actually inspect resource types. I don't think a semantic version number is helpful here, since the different existing combinations of resources types are not expressible linearly. There's no really good answer here, but the only real answer is making sure it's easy for people to generate the docs themselves for their actual deployment. In my observations there could be a few private clouds generating user docs based on upstream, but there have to be many, many more private clouds than public, so it's better if docs.openstack.org can take on the work here for sharing the docs burden for users specifically. Because we've had multiple inputs asking for heat docs that are released, I'd like to see Gauvain's naming/numbering go into upstream. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Maybe continuous deployers should continuously deploy their own docs? For any given cloud the only thing that matters is what it supports right now. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. The original question was about docs.openstack.org, and in that context I think tying it to the release version is a good choice, because that's... how OpenStack is released. Individual clouds, however, really need to deploy their own docs that document what they actually support. We only really release two types of documents - the Install Guides and the Configuration Reference. We have purposely continuously released user guide info and the HOT templates fall under that category. So this document will be updated any time someone gets a patch merged. Because of this CI for docs, labels are critical to aid understanding. Anne The flip side of this, of course, is that whatever we use for the version strings on docs.openstack.org will all make its way into all the other documentation that gets built, and I do understand your point in that context. But versioning the standard library of plugins as if it were a monolithic, always-available thing seems wrong to me. We do the same thing with HOT's internals, so why not also do the standard library this way? The current process for HOT is for every OpenStack development cycle (Juno is the first to use this) to give it a 'version' string that is the expected date of the next release (in the future), and continuous deployers who use the new one before that date are on their own (i.e. it's not considered stable). So not really comparable. cheers, Zane. ___ 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
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On 15/09/14 16:55, Anne Gentle wrote: On Mon, Sep 15, 2014 at 11:31 AM, Zane Bitter zbit...@redhat.com wrote: On 14/09/14 11:09, Clint Byrum wrote: Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. Standard Library implies that everyone has it available, but in reality operators can (and will, and do) deploy any combination of resource types that they want. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. We already have API calls to actually inspect resource types. I don't think a semantic version number is helpful here, since the different existing combinations of resources types are not expressible linearly. There's no really good answer here, but the only real answer is making sure it's easy for people to generate the docs themselves for their actual deployment. In my observations there could be a few private clouds generating user docs based on upstream, but there have to be many, many more private clouds than public, so it's better if docs.openstack.org can take on the work here for sharing the docs burden for users specifically. Yes, although we have to recognise that those docs will only be accurate for clouds that installed Heat right out of the box. Every operator is free to add, remove or even override any resource types they like. Because we've had multiple inputs asking for heat docs that are released, I'd like to see Gauvain's naming/numbering go into upstream. Right, I totally agree :) Gauvain's scheme seems like the right one to me; I was arguing against Clint's suggestion. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Maybe continuous deployers should continuously deploy their own docs? For any given cloud the only thing that matters is what it supports right now. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. The original question was about docs.openstack.org, and in that context I think tying it to the release version is a good choice, because that's... how OpenStack is released. Individual clouds, however, really need to deploy their own docs that document what they actually support. We only really release two types of documents - the Install Guides and the Configuration Reference. We have purposely continuously released user guide info and the HOT templates fall under that category. So this document will be updated any time someone gets a patch merged. Because of this CI for docs, labels are critical to aid understanding. +1, right now we constantly get questions from people reading the docs but running Icehouse about why some brand new feature or other that we merged yesterday doesn't work. So there is no disputing the need to add some sort of versioning information, and I think the first supported release is probably the right information to add. cheers, Zane. Anne The flip side of this, of course, is that whatever we use for the version strings on docs.openstack.org will all make its way into all the other documentation that gets built, and I do understand your point in that context. But versioning the standard library of plugins as if it were a monolithic, always-available thing seems wrong to me. We do the same thing with HOT's internals, so why not also do the
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
Excerpts from Zane Bitter's message of 2014-09-15 09:31:33 -0700: On 14/09/14 11:09, Clint Byrum wrote: Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. Standard Library implies that everyone has it available, but in reality operators can (and will, and do) deploy any combination of resource types that they want. Mmk, I guess I was being too optimistic about how homogeneous OpenStack clouds might be. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. We already have API calls to actually inspect resource types. I don't think a semantic version number is helpful here, since the different existing combinations of resources types are not expressible linearly. There's no really good answer here, but the only real answer is making sure it's easy for people to generate the docs themselves for their actual deployment. That's an interesting idea. By any chance do we have something that publishes the docs directly from source tree into swift? Might make it easier if we could just do that as part of code pushes for those who run clouds from source. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Maybe continuous deployers should continuously deploy their own docs? For any given cloud the only thing that matters is what it supports right now. Thats an interesting idea, but I like what the user wants is to see how this cloud is different than the other clouds. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. The original question was about docs.openstack.org, and in that context I think tying it to the release version is a good choice, because that's... how OpenStack is released. Individual clouds, however, really need to deploy their own docs that document what they actually support. Yeah I hadn't thought of that before. I like the idea but I wonder how practical it is for CD private clouds. The flip side of this, of course, is that whatever we use for the version strings on docs.openstack.org will all make its way into all the other documentation that gets built, and I do understand your point in that context. But versioning the standard library of plugins as if it were a monolithic, always-available thing seems wrong to me. Yeah I think it is too optimistic in retrospect. We do the same thing with HOT's internals, so why not also do the standard library this way? The current process for HOT is for every OpenStack development cycle (Juno is the first to use this) to give it a 'version' string that is the expected date of the next release (in the future), and continuous deployers who use the new one before that date are on their own (i.e. it's not considered stable). So not really comparable. I think there's a difference between a CD operator making it available, and saying they support it. Just like a new API version in OpenStack, it may be there, but they may communicate to users it is alpha until after it gets released upstream. I think that is the same for this, and so I think that using the version number is probably fine. ___ OpenStack-dev mailing list
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
Le 2014-09-08 17:10, Anne Gentle a écrit : On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy sha...@redhat.com wrote: On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote: On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org [1]. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ [2] ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? IMHO it should match the releases and tags (https://github.com/openstack/heat/releases [3]). +1 this makes sense to me. Couldn't we have the best of both worlds by having some logic in the docs generation code which maps the milestone to the release series, so we can say e.g Supported since 2014.2.b3 (Juno) I agree with the matching of releases, but let's set expectations for how often it'll be generated. That is to say, each tag is a bit much to ask. I think that even each milestone is asking a bit much. How about each release and include the final rc tag (2014.2?) This option looks good to me. Gauvain This would provide sufficient detail to be useful to both folks consuming the stable releases and those trunk-chasing via CD? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [4] Links: -- [1] http://docs.openstack.org [2] https://review.openstack.org/#/c/116443/ [3] https://github.com/openstack/heat/releases [4] 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. We do the same thing with HOT's internals, so why not also do the standard library this way? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy sha...@redhat.com wrote: On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote: On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? IMHO it should match the releases and tags (https://github.com/openstack/heat/releases). +1 this makes sense to me. Couldn't we have the best of both worlds by having some logic in the docs generation code which maps the milestone to the release series, so we can say e.g Supported since 2014.2.b3 (Juno) I agree with the matching of releases, but let's set expectations for how often it'll be generated. That is to say, each tag is a bit much to ask. I think that even each milestone is asking a bit much. How about each release and include the final rc tag (2014.2?) Anne This would provide sufficient detail to be useful to both folks consuming the stable releases and those trunk-chasing via CD? Steve ___ 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
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote: On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? IMHO it should match the releases and tags (https://github.com/openstack/heat/releases). +1 this makes sense to me. Couldn't we have the best of both worlds by having some logic in the docs generation code which maps the milestone to the release series, so we can say e.g Supported since 2014.2.b3 (Juno) This would provide sufficient detail to be useful to both folks consuming the stable releases and those trunk-chasing via CD? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Defining what is a SupportStatus version
Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? IMHO it should match the releases and tags ( https://github.com/openstack/heat/releases). -Angus Gauvain Pocentek Objectif Libre - Infrastructure et Formations Linux http://www.objectif-libre.com ___ 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
