Permanent banner when running XOA from the sources #4175
Comments
|
Hi! Thanks for your feedback. However, usability isn't hurt because you can just scroll to get it rid from your field of vision. Also, we had to put this because we had more and more people coming to us on various channels expecting a level of support we couldn't provide outside a tested/validated platform (XOA). This caused a visible impact on our developers availability to actually work on the project itself. |
|
Having the banner is fine, but not being able to remove it is what's not cool. At best, it's a half baked addition to help limit the workload of the devs. At worst, it's an annoyance designed to compel users to purchase support. If I build from source, I know support isn't provided, and not having that banner never indicated to me that it was. |
If you want to remove it, thankfully this is open source. Remove:
|
|
Yea you (barely )beat me to it. HERE is a script I just finished up to remove it. |
We added this in plain sight (it's even in the changelog) so please stop to think it's an evil move. Especially when it's something that's one line you can remove easily or even just scroll to make it disappear. So this is really to tell the majority of users we can't assist if they don't dig a bit before adopting the product. |
|
If you've used my script to install from, this change has been removed as well pending further testing. The support clause is very clear and the end user should know who to go to when looking for assistance, but it is annoying. @olivierlambert keep up the great work, amazing product. |
|
Thanks @Jarli01 Also I'm closing the issue but keep the discussion open. Just know that's hard to find a balance between getting everyone happy using it for free while having 6 full time devs to pay, plus having a flat and cheap pricing for companies. I really wonder how a few pixels height banner could prevent you to use the software. I think the main disagreement is the level of annoyance caused by this message. IMHO, it's nothing for a basic usage: if you want basic features for free (like XenCenter) without the banner, XOA Free exists. If you want all features for free, then you are doing backup and schedule advanced stuff, where a banner can't hurt the usability at all. So @FoxieHazmat and @lastdeadmouse I'd really like to know if it's a real usage problem for you, or just a question of principle (which is fine, but I need to understand what's the real issue for you, and really I'm open to hear anything) edit: I'm also open to suggestions to find something that's fine for everyone 👍 |
|
So something I'd be cool with (from a dev perspective of I took your code and scripted it would be an information tab (maybe even from the "No Support" that can be enabled on XOA for use to point people to the appropriate GitHub/GitLab repo. So that rather than saying "No Support" it'd say something like "Community Support" with a clickable page that could be filled in relatively easily by people like me to point people to create their issues on those separate GH/GL repos first before hitting up the XO Dev team. |
|
Figuring out a way to drive people to the appropriate place, especially in the case of I used this install script and now I'm having an issue is the bigger part. Right now the about page directs people to https://xen-orchestra.com/forum/ and https://github.com/vatesfr/xen-orchestra/issues/new Maybe us just changing or having a point of reference to change that content would be good? |
So you are punishing the majority of homelabbers, who literally cannot pay for support, for the small amount of businesses who are careless and ignorant?
I would say it is impossible for anyone to find XenOrchestra, decide to go the 'from the sources' route and compile it, without seeing that it isn't an officially supported medium. Which means that if they are going to ignore the warnings on the site, Github repo, and the pop-up on every first login of XOA, they are going to ignore the banner as well.
I don't see this as a valid argument, sorry. Micro$oft is pretty clear about its data collection on w10, still evil. Not meaning to be rude here, and I wouldn't call this and evil move but it is the banner that is the issue, not the way it was merged into the source and announced.
I would say both.
You guys are currently doing amazing work bringing Xen management to every device. I understand it is a balancing act when trying to run a business but reminding non-paid users they aren't giving you money no matter what they are doing isn't the way to go IMO, but I think that answer is going to be different for every person. @Jarli01 I appreciate it. Interested to see how you handle it. |
|
@Jarli01 I think that might be an interesting thing:
|
|
We are not punishing anyone, it's a banner, not a feature removal. I still don't get why you see a banner you can scroll down as a punishment, really? Don't you think it's a bit of overreacting?
That's why I'd like to have a "depassionate" discussion about this, so technical arguments are able to make us change our mind, not just complaining for complaining 😉 I'll see for adding maybe a small cross to close the message. |
|
So just for a test, I just changed the bug tracker to point directly to my GH page for issues/new and it worked just find. I'm find with making this change on my script, but I also don't want to stop legitimate bugs from making it to your team. |
|
You could always do the triage and then send people after initial report :) In a way, your own report will be probably more relevant because of your XO knowledge and then lead to faster bug resolution! |
|
@FoxieHazmat how did you build specifically, did you use a script (like the one from my GH) or did you follow the direct build process from the XO website? Which, of course anyone using the direct build process would forever have to deal with the bar/close out. |
I try, surprisingly there haven't been ANY reported issues on my GH at all recently. No new issues reported to me. Since all my script does is automate your install process most of the time the issues resolve around NPM issues. Which 19.04 has some and I made a issue about it on my GH lol. . . |
|
@Jarli01 it could change if you modify the link/banner content or add some links into your build, don't you think? Obviously, people tend to think your script is official or something like that, so we got them directly in forum or GH (or even our livechat on xen-orchestra.com…) Also I'd like to thank you all for the discussion, as you can see the goal here is to find the best solution for everyone, there is no definitive choice! |
|
And that's what I'm considering, but I also don't want to remove YOU as a support option, but would be happy to drive people to the appropriate place first. Which @FoxieHazmat and @lastdeadmouse we kind of need to know, how did you install? |
|
@Jarli01 fair point. Maybe add a link to community support pointing to you as first responder and having a link for people who want profesionnal support pointing to us (ie XO website)? At least something like that in the principle, what do you think? |
|
@olivierlambert Don't get me wrong, I'm not going to stop using your software, nor am I tilted at all about this. I just think that it is a silly way to address a bigger problem. Sorry if I am coming off heated or offended.. I mean, there is already a 'No Support' orange button on the toolbar, what is the banner doing that that doesn't? Perhaps let that orange button become a place where users can hit the xoa(Now xcp-ng/xoa I think?) forums as well as a place to have people who make these install and update scripts implement their own troubleshooting/ bug report avenues. |
|
I wouldn't be opposed to it, but I'd also like to avoid making customization's post install, because my script literally follows your process. The difference being that people can use just about any OS so it isn't a controlled system. So if there was a simple option in the about page that could get filled in post install via |
|
@FoxieHazmat can you answer my question? |
|
Oh sorry, yes I learned how to do it completely manually so I am semi savvy with troubleshooting but I typically use your script just because its easier. Why reinvent the wheel. |
|
@FoxieHazmat just to give you some figures:
So there is a very tangible difference between the 2. As I said, we'll try to find a middle ground solution |
|
@olivierlambert to ask, if someone used the SLI process you have listed, does that version have the banner? |
|
SLI process? |
|
Single line installation (from the hypervisor console) |
|
Deploy script is deploying XOA Free, which get the updater and QA (but with limited features, so there far less support generated on it, it's like a "XenCenter" like). So you don't have the "from the sources" banner because it's not installed from the sources :) |
|
Okay so the options as far as I can see is either you add "Community Support" area somehow, at least with my script I could But that would only affect people who use my script and not everyone else who may use something else or literally build from source.
|
|
And while I agree that, there is no great option here and I'm happy to help where I can. Of course being the development head, it would be beneficial to keep you involved, even if remotely. (Does that make sense). |
|
I think the link here is a good idea and a good start. I'll probably talk with other 3rd party installer providers to ask for a similar thing 👍 The idea (in the end) is to reduce the triage for issues not related to XO itself but the environment. |
|
I am going to argue that the banner clicks are merely because it is a new button.. Who doesn't upgrade something and then check out the new features? I am curious to see analytics after a month when everyone is used to the banner. I have never reached out to XOA support so I could be being ignorant here: but I know with the free version there is a required registration inside XOA but not when you are from the sources, could you force users to login with that account before they can support a ticket? Perhaps a ui color change? XOA red for supported installs and the blue for source installs (bc it matches the blue logo on your repo.) What about changing the versioning scheme? 5.40-F (free), 5.40-S (support), etc and force a full version to be given with every ticket/chat window. |
|
No, versioning changes aren't an option and are just a bad idea in general. What should occur is the types of changes like I've put into the install on my local installation here. Color changes also don't make sense. The issue that @olivierlambert has is there are a lot of people who are going to @olivierlambert for assistance with things like "How do I install this" when they shouldn't be, unless in the explicit case of "Installing from source" by following his documentation. Which they should be able to read and do, if not maybe @olivierlambert you should point people to a GH repo you prefer for the installation process and start calling it something like "XenOrchestra Community Edition preferred installation" Where the dev of that GH repo can make these changes and ensure that people are driven to the correct location for 1st tier support issues. |
@Jarli01 but we already got one central point to tell people how to install it: our doc. But a lot of people are using Docker/3rd party scripts without even reading our doc on how to install it. What could we do then except advertising inside XO itself? |
So for this part that is why I'm thinking if you can say for a fact that people are reporting that my GH is the cause of your bane, to solidify that script as the "preferred" or even "beta" channel and say If reading is to flipping difficult here is a script, if you need assistance please speak with them first. 😆 Of course, that only would address the 1 script (if you chose 1 script) and not the who knows how many others that exist. |
|
Can you rephrase @Jarli01 I'm afraid I don't understand what you mean, sorry (I'm exhausted today so it doesn't help me :D ) |
|
If you pick one of the many scripts that exist, and tag it as the "we'd prefer if you used this 3rd party install script" it would remove a lot of the random issues. That script and dev could work with you to make changes to things like the support link for issues on the bug tracker. |
|
I'm not sure I want to do this. Because then we'll rely on someone outside XO devs to maintain an installer script. edit: there isn't hundreds of popular 3rd party scripts, so it will just require that I contact them and ask kindly to modify some links to reduce our support burden that's not directly connected to XO itself 👍 |
|
@olivierlambert that I thought about as well, but the alternative is you have a million scripts, none marked as better than the others and millions of people all going to your team looking for help as a first channel. |
|
You posted after my edit, I would say 3 most popular scripts will cover probably 80%+ of the issues :) |
Instead on deciding on metrics, wait to decide on if this banner fixes the root problem. If you adopted an 'official' outside script that would be community backed, it would not only be centralized and easy to point to in XOA, but it would be off your shoulders. Then the 80%+ of the manual build issues are going to grow to 99%+ of those issues because if there was an official avenue they would utilize that rather than building it themselves or looking for a script themselves. I can't say I would be much help, but I would volunteer to help people in that community, if it existed. I understand that a community currently exists but obviously it isn't being used. |
|
@FoxieHazmat my script is one of the heaviest used for this project. We could use all of the support you had to offer. |
The issue as I see from a "I'm a part of the problem" is that support cost a lot of money, and FOSS software can only offer so much support. Edit: Or to get people who use a script to go to those script authors /Edit @olivierlambert needs to get the people who've scripted to offer more support for their portion of it, so the product can continue to grow. The forums should still be used, but as a secondary issue. IE I made an issue here, and those devs think it's an upstream issue, can Vatesfs take a look and see if it is? |
|
The one thing I see as an issue @olivierlambert is even if people install from source, the support channel is you and no one else. If you're stating you can't offer support for that route at all then there is a bit of an issue as that is the official "build it yourself route". |
I'd love to! Yours has been my preferred script to use. Perhaps the key to growing and becoming adopted by all is good support. I will do what I can. Have you considered adding a line in your scripts' READMEs to help direct installing and updating questions and issues to your GH first to try and intercept? As @olivierlambert said it may not be obvious to everyone else. |
|
I haven't but if you'd like to create a PR for them I'd be happy to review and accept the changes if they make sense. :-) |
|
@Jarli01 it's not an issue if people follow our official doc in details and install it manually, because it means:
So in theory, the main "problem" is people without enough knowledge using 3rd party scripts in general. I think we got a good base of thinking thanks to this conversation, so I'll gather XO team ASAP and discuss about the options. |
|
Perhaps it would be better to replace the "No Support" with a "Community Support" link to a dedicated sub forum for XO from sources. No support is easy enough to ignore, but "Click here for support" may direct users to more appropriate channels. The banner on install, even upgrade, would be fine with me as long as there were an option to disable it. |
|
Salut, may be late but I was thinking that's great to have a CE packaged by your community as 3rd party scripts ! It provides a quite large diffusion and offer choices for sys. op. to test, try, and adopt your app. But I think something is missing : add the ability to install your "turn key appliance" from the CE version. See, if someone want to test your app I don't know if he is willing to run a script on his cluster 🤣 even if you says "It's ok it will not harm anything". But if he start by using Docker, or a 3rd party install script and if a way to push the XO Free version to his cluster is provided by the app may be it will be easiest to switch from the CE to the official appliance right after his tests (and avoid any issues related to a clumsy CE packaged version). This way no need to say "Hey ! No support here !" on the CE version but just "You have an issue ? First check the XOA Free version: it's one click". |
|
@Ezka77 I totally agree and that's why we have a web deploy solution integrated in XCP-ng 8.0 default HTML UI (see https://xcp-ng.org/forum/post/11993) We don't want to support a Docker version right now, that's why we pushed for an easier deploy that doesn't require typing a command in a shell. Note that we'll also have a deploy directly from the web browser just by visiting a page on xen-orchestra.com, helping again to get very very easy XOA to test. |
|
I know this is old... but I wanted to add my 2 cents here because I don't think anyone has suggested the following (not that I have seen) and because I think it addresses both sides of the issue. The way I see it is that the CE users are generally annoyed that the "nag notice" consistently returns after acknowledging they are using a source install. And @olivierlambert is annoyed that users are "But a lot of people are using Docker/3rd party scripts" without referring to the creators of those scripts for support. It is 100% understandable that 3rd party scripts are not supported. (but not everyone reads esp people that are just 'testing' XO CE and barely know how to manage a server to start with. (I think seasoned admins do not have this issue and look at the documentation) So I think that mostly we are looking at 'new' adopters of the technology as a whole. So to address the issue of "But a lot of people are using Docker/3rd party scripts" it seems logical that perhaps there is an official build script to build and install XO CE, or even a prebuilt xva for the CE edition alongside the XOA edition. This would kind of eliminate the need for any 3rd party scripts for installations. In the case of the XO CE as an .xva download, you could just have a nightly build script that builds and publishes a nightly build. If someone wanted to "upgrade" they would have to back up their config install a new VM and restore the config vs now where one might just run @Jarli01 Would it really hurt if someone acknowledged that they were using the CE, and that a check bit was saved in the config to not show the notice again until they upgraded to the next version? As to the Docker issue. I understand that supporting a docker version may not be on the roadmap. But again it would eliminate that issue. Personally, I do like docker images as they are easier to manage and update as a whole over other options. I do not think that there is anything anyone could do about this except provide an official version. For the longest time, Zabbix refused to offer a docker image. As a result, several community versions popped up with monitoring artist being one of the most downloaded versions. With some of those being over 50+ million downloads! This made Zabbix reconsider, and now Zabbix offers an official docker image, even though it is not recommended for production use. The end result? monitoringartist images have not been updated in years. Why... because most users started to just use the official Docker image. And when they moved to the official docker image, there was no need for the monitoringartists images any longer. The point of this is that in the absence of a supported architecture or platform, with open-source software a community user will likely fill that nitch if there is a need. This is a good thing, but the end users likely are not technically adept enough to understand who the responsible parties are. I would say one last thing about WHY you might want to consider an official Docker image. I for one do this very thing and run XO CE on a digital ocean VM connected using tailscale as the VPN to my home lab. I am able to see my lab from anywhere in the world without having to have direct access or opening ports on my firewall or having to have a dedicated VPN connection on a mobile device. And while I run this as a VM, I would much rather have had it as a supported Docker image. Well that is my two cents. I hope it was useful. -- P.S. I am also a paying XO subscriber for our production installation but use XO CE personally and as a demo to interested parties. |
|
Thanks for your input. It's 2 different "problems" (bundling and "nag" screens), I don't see the connection between them.
You are raising an interesting thing however: providing a "demo"/SaaS version of XO to test it very quickly. I have this in mind since a while, but it's not yet very high in the backlog :) |
|
A SaaS version (Hosted XO) I think could be a good option, if it was affordable. (I have to admit that XO is a little pricey esp for smaller companies. Esp, if you're trying to use the more advanced backup options. I still have clients that just install a copy of Windows as a VM and run Xen Center, because its far cheaper. I do wish the CE could have 1 proxy though :) |
|
@tuxpowered we'll have bundles coming in the next months, with both XCP-ng and XO into a single offer. So this will solve the small company pricing issue. |
Context
Expected behavior
Current behavior
Just updated to 5.34. Can't disable the banner notification? Whats up with that? I am sure everyone who manually builds XOA understands the risks; there are warnings everywhere. I am all for that, but hurting the usability of the software because people won't/can't purchase support? Not FOSS, not cool.
Referring To - "[XO] Add banner for sources users to clarify support conditions #4165 (PR #4167)" In the changelog
The text was updated successfully, but these errors were encountered: