[GENIUS-190] Remove upgrade-in-progress flag from GENIUS Created: 26/Jul/18 Updated: 01/Mar/19 Resolved: 01/Mar/19 |
|
| Status: | Resolved |
| Project: | genius |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Sodium |
| Type: | Task | Priority: | Medium |
| Reporter: | Faseela K | Assignee: | Faseela K |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
This flag is already migrated to serviceutils. However, for backward compatibility the flag in genius is retained, and re-directed to the one in serviceutils. We should remove this once the northbound starts using directly the flag in serviceutils. jhershbe : please let me know from where and all this flag is currently being set, and how easy it is to move to the serviceutils flag. Based on that we can decide on the timelines on getting this flag removed from GENIUS. |
| Comments |
| Comment by Michael Vorburger [ 26/Jul/18 ] |
|
As far as I understand, we (Red Hat) now have installation tooling scripting which sets this (via RESTCONF), so we need to be careful and synchronize here... jhershbe, trozet and JankiChhatbar are the right people to talk to about this. |
| Comment by Vishal Thapar [ 26/Jul/18 ] |
|
Plan is to not remove it in current release, that is why I added patch in genius to set new flag based on old one. Deprecate it in flourine and then remove it in Neon towards the end. In meantime we can move code in elan etc. also to use the new flag. |
| Comment by Michael Vorburger [ 26/Jul/18 ] |
|
What I trying to point out is that even after all code in ODL like elan etc. has migrated, there is still a need to carefully synchronize this, because our installation setup tool (TripleO, EXTERNAL to ODL Java code) sets this. |
| Comment by Vishal Thapar [ 26/Jul/18 ] |
|
I know, that is why I said we don't want to remove old flag till Neon release and usage of it till it is appropriately tested. One full release is sufficient time to make changes in TripleO etc. |
| Comment by Tim Rozet [ 31/Jul/18 ] |
|
If there is a config change in ODL, please make a Jira for the config change with the version it applies to in integration-packaging puppet-opendaylight and assign to me or JankiChhatbar |
| Comment by Janki Chhatbar [ 04/Dec/18 ] |
|
Reiterating what trozet is saying - if there are any file/config changes needed for this migration, we need to make appropriate changes in puppet-opendaylight apart from TripleO change that dfarrell07 pushed. If yes, we would need a new Jira and assign it to either one of us. |
| Comment by Daniel Farrell [ 04/Dec/18 ] |
|
JankiChhatbar Maybe I'm missing something, but I don't think puppet-opendaylight touches anything related to this config. I think it's only used by the external TripleO upgrade logic. |
| Comment by Janki Chhatbar [ 05/Dec/18 ] |
|
Currently it doesnot. But if this change needs, then we should make those changes in puppet-opendaylight. But doesnot look like it will. k.faseela can you please take a look at this karaf error I am seeing https://jira.opendaylight.org/browse/INTPAK-218?focusedCommentId=65873&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-65873 |
| Comment by Michael Vorburger [ 05/Dec/18 ] |
|
I've just replied with an analysis over in INTPAK-218; let's use that issue instead of this one to discuss it. |