webui-vue first impressions
gmills at linux.vnet.ibm.com
Fri Aug 21 00:18:02 AEST 2020
On 8/17/2020 11:34 AM, Ed Tanous wrote:
> "Ed, what would it take for you to switch to using webui-vue?"
Thank you for your feedback.
> What follows is my first impressions on an answer:
> 1. size parity with phosphor-webui.
> On the current master, webui-vue has a 40% larger binary footprint
> (614kb vs 440kb) and is still missing features that will add size.
> Lots of bmcs run on 32MB of flash, so every kb matters, even if it
> doesn't matter for the newer platforms with eMMC or larger SPI flash.
> webui-vue needs to sort out where that extra heft came from, and
> eradicate it.
It was smaller than phosphor-webuiuntil recently.
back under the size of phosphor-webui.
If we care about flash,we should look at removing or reducing the size of
> 2. A more thorough list of deficiencies in comparison to phosphor-webui.
> There's a "feature parity" list on the readme that makes it seem like
> it's closer than it is in practice. In the course of writing the
> patchset above I found that webui-vue doesn't support Mutual TLS,
> doesn't support CSRF allow list (a security feature), and doesn't
> support the "next" url forward. None of these are listed in the
> feature parity list. Considering that's just what I found in the
> initial look for the above patchset, I'm guessing there's more use
> cases that got overlooked. If we're dropping use cases, we need to be
> explicit about it, and document why.
Yeah, we clearly missed some features that were in phosphor-webuiwith
the rewrite. I opened some issues for these and the others we know
about. IBM will work onthe "next" URL forward. For features implemented
in phosphor-webuithat we don’t plan to support will need to
reimplemented by the community in webui-vuebut I don’t think there
should be many and for joining us on webui-vueyou get a theme-able,
translatable, fully Redfish, and actively developed GUI. 😊
Can you further explain what CSRF allow list feature we had in
> 3. Chunked payloads
> webui-vue opts for multiple chunked bundles. In phosphor, this single
> bundle was done on purpose. Chunking works great for CDNs and
> multithreaded webservers, but tends to cause slower page loads when
> done on a bmc, as bmcweb is largely optimized for single connection
> single client single request. Although it's able to handle multiple
> clients and multiple connections, the bmc NIC tends to get "starved"
> of bandwidth for other things, which can cause performance degradation
> if you have lots of things going on in parallel. I'd recommend going
> back to the old paradigm, unless there's a good reason to chunk from
> the BMC. Note the bmcweb router holds all static routes in memory
> under the assumption that there won't be very many of them. With
> chunking, that's no longer true, and probably causes some unnecessary
> increased memory usage.
After some discussion, we agree and
js, html, and cssfiles as phoshor-webui.
> 4. A more stable migration strategy
> The changeover to vue got started completely from scratch, and got
> mixed with DOM changes that functionally changed the UI. If this was
> to learn vue, and build a toy UI, that would've been fine, but the
> fact that it's now its own full repo means we have fork problems, give
> that there is no stable and specified bmcweb->phosphor-webui
> interface. It would've been relatively straightforward to move
> phosphor-webui over to vue, by keeping the existing DOM, CSS, and
> layout, while replacing the templating and router with vue, but the
> decision was start over completely from scratch, and now openbmc has 2
> "official" webuis. I probably missed the discussion on why a hard
> throwaway was needed here, but it seems like a series of patches that
> ONLY moved over to vue would've been much easier to manage here for
> the community as a whole, as each step of the way we can verify
> feature parity when reviewing patchsets.
In theory but we don’t think it would have been straightforward. Had we
gone with a transition it would have forced all users into this
vuerewrite, potentially some in-between larger GUI while it was in
transition. Phosphor-webuisuffers from some anti-patterns (some of the
reason why it took such crazy large commits to do any theming), we don’t
think we could have reached where we are today with a transition approach.
A separate repo we felt was the safest bet. This two repo approach
doesn’t limit the community from moving forward as the webui-vueis
maturing. This approach has been used in the community before.
> As is (ignoring Kathys
> patches for a moment) there are 4 patchsets open for phosphor-webui.
> Is there a documented strategy for who is responsible for moving them
> over to webui-vue? I didn't see anything written down, which leads me
> to believe there's no plan.
After “ignoring Kathyspatches”, I don’t see any other commit except your
“Add the option to use backend login routines”, that isn’t up for review
(Virtual Media) or already in (“Relace node-sass with dart-sass" and
“expired password”) webui-vue.
As mentioned, we know we are missing some feature parity and are looking
for help from the community (raising any problems or contributing) but
we have done a lot of work to get where we are, every page on the
existing webuiexcept SNMP and Virtual Media is in webui-vueand
webui-vuehas a lot of advantages.
IBM has moved 2 of their systems to webui-vue
> 5. Missed opportunity with Redfish UI
> If you're going to build a redfish first GUI, it seems like an
> opportunity where we could've used the CSDL definitions to drive and
> build a lot of the UI automatically. Given that phosphor-webui
> doesn't do this today, this wouldn't have kept me from using
> webui-vue, but the idea that the UI can simply build itself for the
> "easy" stuff would be a massive win on productivity, and would
> probably make me more personally inclined to go help sort out 1-4
> above, as I think the end would justify the means. As is, it takes a
> very similar "hardcode every page" approach that the phosphor-webui
We don’t see how we could reasonably do this. Would need more discussion
We also think there would be some trade-offs e.g. those Redfish Schemas
are quiet large and today are really only needed for Redfish validation,
using them in the GUI puts another requirement on them.
> Don't get me wrong here, I think all of the above can be fixed, and we
> certainly could have a great Vue based webui that works for everyone,
> but right now, the rather arbitrary "the project will stop supporting
> frameworks and modules go unsupported all the time, and we're using
> several "unsupported" modules today to no ill effect.
We disagree some, we do think there is ill effect of being on an
regularly and has an active community.
> Theming is a
> nice feature, but those are mostly DOM and CSS changes, and are
> unrelated to a changeover to Vue. Translations was attempted in
> phosphor-webui in the past, but to quote the review:
> "neither any clients nor any companies wanted OpenBMC translated."
IBM does have a requirement on translation and we have heard in the GUI
workgroup meeting, other companies would be interested in translation as
> Also keep in mind, I have very little seat time in webui-vue, the
> above is mostly first impressions in response to the ask from Gunnar.
> Overall, if the above can be fixed, I'd probably move to webui-vue.
Appreciate the feedback, was really helpful.
Gunnar, Yoshie, and Derick
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc