[new-product] Add Veritas NetBackup #7535
Conversation
|
I did originally condense the release cycles (e.g consider 5.1.1 MR5 as part of the 5.1.1 release cycle) but some of them have different EoSL dates (hence why it might be failing?) |
@baggers27 each cycles need |
Set releaseColumn to false and fixed formatting on releaseCycle
|
I think I've fixed the releaseCycle names and I've set the releaseColumn to false. |
|
Current problems : |
Fix EOL vs EOS
Fix 3.1 and 3.1.1
Fix typo
There was a problem hiding this comment.
Product Validator: Invalid releases '5.1.1.mr5' for veritas-netbackup.md, expecting release (released on 2024-08-28) to be before 5.3 (released on 2023-11-27).
Product Validator: Invalid releases '5.0.0.1.mr5' for veritas-netbackup.md, expecting release (released on 2023-11-08) to be before 5.1.1 (released on 2023-02-08).
Product Validator: Invalid releases '4.1.0.1.mr5' for veritas-netbackup.md, expecting release (released on 2023-02-14) to be before 5.0 (released on 2022-04-25).
Product Validator: Invalid releases '4.0.0.1.mr4' for veritas-netbackup.md, expecting release (released on 2022-06-13) to be before 4.1 (released on 2021-07-19).
Product Validator: Invalid releases '3.3.0.2.mr2' for veritas-netbackup.md, expecting release (released on 2021-11-12) to be before 4.0 (released on 2021-03-01).
Dont forget that releasecycles should be ordered with their releasedate not with their releasecyclename ( title ) so these 5 should be reordered with their releasedates ( not with their number).
Also It might look much better if you use - instead of . betweek mr parts
( i mean for example instead of 5.3.0.1.mr4 -> 5.3.0.1-mr4 looks much better )
|
I'm not sure what to do about the MR releases. Per previous comment, I did originally condense the release cycles (e.g consider 5.1.1 MR5 as part of the 5.1.1 release cycle) but some of them have different EoSL dates. So let's say I flatten it and just do "5.1.1" as the release cycle and have "5.1.1-MR5" as the "latest" release, I'm guessing that might satisfy the linting, but there are two different EOL dates, so that can't work - a customer on 5.1.1-MR5 would be supported but MR4 wouldn't. So I think they need to be separate but it's causing the linting to fail? |
Orders the releases by their date Change .mr -> -mr style Add spaces between cycles Cosmatics changes
|
@baggers27 I have fixed the order problem , could you check if anything wrong or not ? Right now it is linting works perfectly |
|
Right now it is missing an description something like |
|
Ah cheers, I get what you mean about the release date now. I was just thinking about the order within releases - hopefully that didn't take you too long. I had this on the original yaml I created but hadn't spotted that it got dropped, in case you want to use that
Veritas offers full support from general availability for 3 to 4 years. At the end of full/active, support, extended support is available for 1-2 years with no new bug fixes, but access to existing patches and technical help. The final sustaining phase before EOSL lasts for 1 to 6 years with focus on severe service restoration or data retrieval issues. |
|
@baggers27 i will be the reviewer :D you make your changes add needed description at the end like the other products. |
|
btw you can add to |
|
@baggers27 ^^ |
|
btw you can always check how the end result will look like ( if there isnt any error on building ) by : |
|
Cheers - now I can see some of the releases are showing as supported when they shouldn't. I'll sort that and the release labels shortly. |
|
I can see it's failing because I had to take some of EOAS/EOL dates out where it's not clear whether they were supported or not. I thought I would be able to copy how the Bootstrap one looks where it just says Unavailable. So not sure how to fix this. |
|
Give me 2 min first i will check what have changed |
|
the problem looks like you forget to add true / false / date for eoes/eol/eoas tags |
|
The ones which have forgetten ones are : |
|
The one for bootsrrap Unavailable thing might be exist because of an old api / not lint checking times that product added |
|
The problem is for some releases, it just says N/A and it's not clear where in the cycle they are. (I was incorrectly showing them all as supported before (false). |
|
Not Applicable means there isnt any support so make it false |
There was a problem hiding this comment.
Thanks for this contribution @baggers27.
I see two main issue with this PR:
- I don't know the specific part of the product it is targeting. Veritas NetBackup seems to be a lot of things: hardware (appliances ?) as well as software (Veritas NetBackup Appliance OS, Media Server, OpsCenter...). And it seems each have its own support policy.
- I failed to understand what are the release cycles: are 5.3.0.1-mr3 and 5.3.0.1-mr4 in the same release cycle ? Why is there so many "Not applicable" mentions on https://sort.veritas.com/eosl ?
I am a bit confused about this product.
|
|
||
| --- | ||
|
|
||
| > [Veritas NetBackup](https://www.veritas.com/protection/netbackup) is an enterprise-level data protection and backup solution |
There was a problem hiding this comment.
Is this about Veritas NetBackup Appliance OS (used as the product name), or about Veritas NetBackup ? Those seem to be separate softwares .
There was a problem hiding this comment.
For this PR, I am specifically referring to the appliance OS which is part of the NetBackup suite, and I can envisage follow-up PRs for the hardware and agent/server software. I can add a line here that says "NetBackup appliances use the Veritas operating system (VxOS), which is a customized Linux operating system." Maybe we should also change the name to VxOS but I wonder if that would be more confusing for people. https://www.veritas.com/support/en_US/doc/96220900-127024912-0/v115997970-127024912
There was a problem hiding this comment.
So Veritas NetBackup Appliance OS is in fact VxOS ?
It seems to me the paragraph is about the NetBackup suite. To avoid confusion it would better to explicitly mention Veritas NetBackup Appliance OS and not just Veritas NetBackup, and describe what it is.
|
|
||
| > [Veritas NetBackup](https://www.veritas.com/protection/netbackup) is an enterprise-level data protection and backup solution | ||
| Veritas offers full support from general availability for 3 to 4 years. At the end of full/active, support, extended support is available for 1-2 years with no new bug fixes, but access to existing patches and technical help. The final sustaining phase before EOSL lasts for 1 to 6 years with focus on severe service restoration or data retrieval issues. |
There was a problem hiding this comment.
On endoflife.date, products with no possibility of bug fixes are usually considered EOL. The reasoning behind that is that is a serious issue occurs and requires a fix, the only possibility you will have is upgrade to the next version.
So IMO it's OK to document extended support / sustaining support in the description, but they should not appear in the release table.
There was a problem hiding this comment.
Looks like the description can be improved as it does not mention security fixes as seen on the following table on https://www.veritas.com/content/dam/support/terms/Veritas%20EOL%20Policy.pdf:
Based on this table, there is:
- An active support phase (full support), with bug an security fixes.
- An security support phase (extended support), with only security fixes.
So this mean the sustaining phase must not appear in the table (but it's nice to document it in the description).
There was a problem hiding this comment.
I will rework and resubmit.
| - releaseCycle: "5.5.0.1" | ||
| releaseDate: 2025-02-12 | ||
| eoas: true | ||
| eol: true |
There was a problem hiding this comment.
This means the latest version is already EOL, which cannot be true. I don't know what Not applicable means, but I doubt it mean there is no support.
There was a problem hiding this comment.
I think based an another comment, if we removing the sustaining phases the eol will go back to being eol (rather than start of sustaining phase) and that would then be set to false (i.e still supported), with eoes (which is currently being used to represent eosl) disappearing.
|
@marcwrobel Thanks for the review. I'll submit an updated PR probably over the weekend, although it might be good to get clarify on some things first.
This PR is specifically for the Veritas NetBackup Appliance OS (VxOS) - please let me know how best to clarify that in the PR. I think I replied to the specific comment on that with a suggestion.
From https://www.veritas.com/content/support/en_US/article.100049781: Note that only the final MR of a major release is eligible for Extended/Sustaining Support. So they are potentially the same release cycle, but I don't see how we could condense it if they have different end dates.
So for 5.1.1 if you had version 5.1.1 MR3, if we showed the MR5 EOL date it might look like you're supported, but if we showed the EOL date for the older MRs, if you were on MR5, you would in fact still be supported. My biggest concern with this PR is the Non Applicables. Effectively it's because only the final MR of a major release is eligible for Extended/Sustaining Support. If we take 5.3.0.1 as an example, I can imagine there is one more MR is come, which will have the support dates populated. But for non-latest releases, like 5.3.0.1 MR4, we know it's somewhere between active support and EoL. The way I'm reading it is that if ta release is not eligible for extended/sustaining support but is not yet past its EoSL, then it must be under active support? If you agree with that, I'll draw up the changes on that basis. |
What confused me the most is the description, which does not mention Veritas NetBackup Appliance OS at all : Veritas NetBackup is an enterprise-level data protection and backup solution ?
WDYT of considering the first two digits as the release cycle ? According to https://www.veritas.com/content/support/en_US/article.100049781:
And it seems to work looking at those two examples: This would solve the "Non applicable" issue as well : Non applicable in this case just means this is not the last MR, so the date is still not known. |
|
Thanks, looks to be an option. I'm struggling to find the focus time to get back to this at the moment so I'm open to someone else making the changes otherwise I'll come back to it in the next few weeks. |
This is a start to addressing #4215. It does not close that issue but this is the first pull request of the OS of the Netbackup appliances. Separate pages may be needed for the Netbackup appliance hardware and software.
Information pulled from: https://www.veritas.com/support/en_US/eosl (under Appliances --> NetBackup). While the website uses start dates for extended support/sustaining support, I have treated these as the same as end of active support/extended support respectively (rather than maybe referring to the previous day).
I imagine new release data could potentially be automated by a custom python script.