-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SAP and HA dashboards to grafana formula #67
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, but I'm not sure this works as it is without configuring packagehub, since the dashboards are not in any SLE channel yet, they're only in openSUSE:Factory.
@renner @cavalheiro @witekest what is your pov on this? ju SLE15 submissions are done for the PKGs. can suma-server install such server or how can we install the dash? tia |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good, AFAIK we ship and support grafana to be installed with this Formula for SLE12 and 15 with the respective SUSE Manager client tools channels (SLE12 and SLE15). I think for consistency we should either package all the dashboards as RPMs and ship those packages with the same client tools as grafana itself or include all the json files with this Formula, including yours.
It all the depends, on what channel(s) is this package? |
@juliogonzalez it is on SLES codebase. Update sent to you on rocketchat |
Uh-oh, I am afraid we are going to have a problem here. SUSE manager its own We can of course take it from SLES codestream as we are lucky and the version there is higher. But then @witekest needs to be aware that the maintenance will happen there by branching the package. And before doing that, I'd like to have his OK in case there's something I don't have in mind right now. Do we really need this for 4.1.1 or can it wait for 4.1.2? I'd really like to avoid yet another last-minute-change, as this was not even at https://github.com/SUSE/spacewalk/issues/11942 or https://jira.suse.com/browse/ECO-2237 on the list of packages part of the ECO. |
As I understood, Dario was referring to the packages that would be installed with the
He submitted those to the SLES 15 channels, so in the current setup this part of the formula works only for systems that have those channels assigned. As mentioned before, I think a more consistent approach would be to either ship those dashboards as json files like the other ones, or provide all dashboards as packages with the same channels as we are providing Grafana itself, i.e. the client tools channels for SLE15 and SLE12.
I don't think it's required for 4.1.1, we should probably aim for releasing this with 4.1.2 and try to get the mentioned packaging / linking done in order to support all platforms where we are support the provisioning of Grafana with this formula? |
I guess the most sensible solution is submitting this update of grafana-formula to the SLE15 codestreams, and having SUSE Manager taking it from there with 4.1.2 (via product definition for devel, or via channel definitions for the release) :-) |
Julio, |
Let me clarify. We have Now the dashboards are a different story, as they it seems they are not maintained by us, IIUC. Therefore we should add them to the SLE15 client tools product definitions and SLE15 client tools channel definitions, but there's no need to to link them or copypac them to our devel projects. Now the question is what happens about other OS: Who is going to maintain the packages for those OS? Us or dario/sap? And where are we going to maintain them? At the OS codestreams so other projects can use them, or at the client tools codestreams (only available as separate codestreams for RES8 and Ubuntu20? |
@juliogonzalez so we are going to maintain the grafana-dashboards rpms packages. However we never tested for RES8/Ubuntu, is this strictly mandatory or the grafana-formula can be more "elastic" in that sense? As stated from @renner , I could submit the If it is strictly mandatory to have RHEL/DEBian packages, we can help you to have such packages. As you can see, we have the RPM here which is automated by github-actions. The dashboard package itself is just a json file |
We are not actually supporting grafana itself for other OSs (RES or Ubuntu), only for SLE12 and SLE15. Therefore - from my perspective - we should just ship Dario's dashboard packages alongside the grafana package with our SLE12 and SLE15 client tools. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me! 👌 As discussed it could be released with 4.1.2, we only need to make sure that those dashboard packages are present in our SLE12 and 15 client tools (alongside grafana).
Ok, then we need @MalloZup to prepare a submission to the SLE12 codestreams (SUSE:SLE-12:Update, and from there it should get into all SPs), as I understand from his comment that he will be the maintainer. With that, we can ask maintenance to modify the channel definitions to take the packages from the SLE channels. |
@juliogonzalez Yes for SLE12 we have in our backlog a plan to submit ECO for dashboards |
@MalloZup what will be the package? Ideally we should have that package available at SLE12 before the second week of September. If it's a new package that for now only SUSE Manager is going to use, you don't really need an ECO if you just want to submit to SUSE:SLE-12:Update, AFAIK |
Also we'll need this updated grafana-formula package submitted to the Devel:Galaxy:Manager:4.1, Devel:Galaxy:Manager:Head and systemsmanagement:Uyuni:Master. I will create a card for you @renner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When trying to apply highstate I'm getting
- "Rendering SLS 'base:grafana' failed: while parsing a block mapping\n in \"<unicode string>\", line 6, column 1\ndid not find expected key\n in \"<unicode\
\ string>\", line 47, column 3"
thx for all reviews. resuming the follow-up todos:
I guess after this we should be ok to merge the PR, or I'm missing something? |
If you want to split the work into smaller steps I'd suggest creating a feature branch and continuing the work there. |
@witekest no worries, if you check my first point is about what you suggest. see #67 (comment) 🌻 |
There's one extra task, which is for SUSE Manager to update grafana-formula on the SUSE Manager and Uyuni codestreams as the package is only there and NOT at the SLE/openSUSE codestreams, and I guess we want to keep it that way). I created an internal card for it. |
@witekest thx for taking care of this. we need to wait to merge this until grafana dashboards lands to sle15 .. |
@MalloZup the packages are on SLE12 and SLE15 already, and you have two approvals and no blockers. Is there anything else pending? |
@juliogonzalez nope nothing pending for dashboards. |
@witekest the grafana pkg are merged so we can merge this unless there are other issues |
@MalloZup you have conflicts on the changelog, you will need to fix them. |
@juliogonzalez the conflicts where caused from 2 hours ago: |
The commit: * updates the namespaces of newly grouped elements * removes packages if disabled * updates the list of watched configuration files
If this is ready to be merged, I suggest you go ahead with it so @witekest can prepare the SRs :-) |
desc:
This pr add sap and ha cluster dashboards maintained by SAP/ha team
I have followed the same pattern you have on the grafana-formula
note that I didn't tested this.
Consideration/Request for comments:
Since we package already our dashboards, putting the json files here would be somehow not the cleanest solution since we would need to maintain
json
here AND in the source code of the original dashboards. ( so more then 2 places)On the other side, I don't remember if the SUSE-Manager server has access to the SLES repository for installing the RPM packages but I guess yes and that this approach should be ok.
let me know