[FOLIO-1730] Create folio/minimal Vagrant box Created: 23/Jan/19 Updated: 27/Feb/23 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Wayne Schneider | Assignee: | Wayne Schneider |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | ci, platform-backlog, platform-minimal | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||
| Sprint: | DevOps Sprint 159, DevOps Sprint 160, DevOps Sprint 152, DevOps Sprint 154, DevOps Sprint 155, DevOps Sprint 157, DevOps Sprint 158 | ||||||||||||||||||||||||||||||||||||||||
| Development Team: | FOLIO DevOps | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
While generating a Vagrant box from the platform-core Stripes platform is useful, it doesn't meet the needs of non-core developers who might want to develop based on a very custom set of modules, and want an even more minimal box, with just Okapi and the dependencies of stripes-core. |
| Comments |
| Comment by Matthew Jones [ 23/Jan/19 ] |
|
Out of curiosity I created a new tenant on my VM and ran a simulate install with only stripes-core to see what would be picked up. $ echo folio_stripes-core | stripes mod install --simulate --tenant diku2
stripes-cli:okapi ---> POST http://localhost:9130/_/proxy/tenants/diku2/install?simulate=true&deploy=false&preRelease=true +0ms
stripes-cli:okapi <--- 200 OK +461ms
[
{
"id": "mod-users-15.3.1-SNAPSHOT.62",
"action": "enable"
},
{
"id": "mod-permissions-5.4.1-SNAPSHOT.36",
"action": "enable"
},
{
"id": "mod-login-4.7.1-SNAPSHOT.41",
"action": "enable"
},
{
"id": "mod-inventory-storage-14.1.0-SNAPSHOT.220",
"action": "enable"
},
{
"id": "mod-password-validator-1.1.0-SNAPSHOT.17",
"action": "enable"
},
{
"id": "mod-authtoken-2.0.5-SNAPSHOT.41",
"action": "enable"
},
{
"id": "mod-notify-2.2.0-SNAPSHOT.69",
"action": "enable"
},
{
"id": "mod-configuration-5.0.2-SNAPSHOT.50",
"action": "enable"
},
{
"id": "mod-users-bl-4.3.3-SNAPSHOT.52",
"action": "enable"
},
{
"id": "folio_stripes-core-3.0.1000492",
"action": "enable"
}
]
Does this seems correct? I was a bit surprised to see mod-inventory-storage. It appears to be required by mod-users-bl because of the service-points and service-points-users interfaces. |
| Comment by Mike Taylor [ 23/Jan/19 ] |
|
This seems like a confirmation of my feeling that service-points should never have been in stripes-core. (In fact, I have a vague memory that we moved them out of stripes-core and an application module handled them using generic facilities; but I could be mis-remembering.) Otherwise this looks about right. I know that stripes-core does depend on mod-users-bl (though I can't remember why). |
| Comment by Wayne Schneider [ 23/Jan/19 ] |
|
That is surprising to me, but I see how it happened. I'm sure it made sense (at the time) to include the service points information in the composite user record returned by mod-users-bl. I can't think of an easy way to disentangle the dependency. |
| Comment by Wayne Schneider [ 23/Jan/19 ] |
|
stripes-core relies on mod-users-bl to provide the /bl-users/login endpoint that returns a nice composite user record with permissions, IIRC |
| Comment by Mike Taylor [ 23/Jan/19 ] |
|
Right, /bl-users/login, that makes sense. And I guess that directly depends on mod-inventory-storage. Rats. I wonder how easy it would be to generate a visual dependency DAG of all the modules? |
| Comment by Matthew Jones [ 25/Jan/19 ] |
Mike Taylor, The latest Okapi v2.23.0 supports returning module IDs in DOT graph format. Adding the dot=true query parameter to the GET _/proxy/modules endpoint will return the graph data. It may be best to limit the number of modules with latest=1 and perhaps exclude preRelease/npmSnapshot versions as well (all the options). For instance: http://localhost:9130/_/proxy/modules?dot=true&latest=1&preRelease=false&npmSnapshot=false The response can then be pasted into a DOT visualizer. There appear to be several browser and desktop options. I've only experimented with this briefly and the results were a bit messy, but I suspect that is in part due to the descriptors/versions I happen to have installed on my VM. Adam Dickmeiss Any recommendations on proper usage or viewer preference? |
| Comment by Mike Taylor [ 25/Feb/19 ] |
|
The .dot output that I get simply consists of a list of nodes with no connections:
digraph okapi {
okapi__2_24_4 [label="okapi-2.24.4"];
mod__rs__1_0_0 [label="mod-rs-1.0.0"];
mod__graphql__1_1_1000199 [label="mod-graphql-1.1.1000199"];
folio_vendors__1_3_1000109 [label="folio_vendors-1.3.1000109"];
folio_users__2_20_1000583 [label="folio_users-2.20.1000583"];
folio_tags__1_3_100029 [label="folio_tags-1.3.100029"];
folio_stripes__smart__components__2_0_1000376 [label="folio_stripes-smart-components-2.0.1000376"];
folio_stripes__core__3_0_3000512 [label="folio_stripes-core-3.0.3000512"];
folio_servicepoints__1_3_100038 [label="folio_servicepoints-1.3.100038"];
folio_search__1_5_1000120 [label="folio_search-1.5.1000120"];
folio_requests__1_7_1000213 [label="folio_requests-1.7.1000213"];
folio_plugin__find__vendor__1_2_100023 [label="folio_plugin-find-vendor-1.2.100023"];
folio_plugin__find__user__1_5_100045 [label="folio_plugin-find-user-1.5.100045"];
folio_plugin__find__instance__1_3_100021 [label="folio_plugin-find-instance-1.3.100021"];
folio_organization__2_7_1000191 [label="folio_organization-2.7.1000191"];
folio_orders__1_1_1000185 [label="folio_orders-1.1.1000185"];
folio_myprofile__1_4_100046 [label="folio_myprofile-1.4.100046"];
folio_inventory__1_6_1000414 [label="folio_inventory-1.6.1000414"];
folio_finance__1_3_100057 [label="folio_finance-1.3.100057"];
folio_eholdings__1_4_1000487 [label="folio_eholdings-1.4.1000487"];
folio_developer__1_7_100039 [label="folio_developer-1.7.100039"];
folio_data__import__1_0_100064 [label="folio_data-import-1.0.100064"];
folio_circulation__1_5_1000191 [label="folio_circulation-1.5.1000191"];
folio_checkout__1_6_1000246 [label="folio_checkout-1.6.1000246"];
folio_checkin__1_5_1000121 [label="folio_checkin-1.5.1000121"];
folio_calendar__2_0_600091 [label="folio_calendar-2.0.600091"];
}
Which produce a very uninspiring diagram |
| Comment by Khalilah Gambrell [ 03/Jul/22 ] |
|
Hey Wayne Schneider. Is it okay to close this story? |
| Comment by Mike Taylor [ 03/Jul/22 ] |
|
I am not Wayne Schneider, but ... No, it's no OK to chose this. As FOLIO's "complete" platform becomes more and more bloated, the need for a minimal becomes ever more important. |
| Comment by Khalilah Gambrell [ 03/Jul/22 ] |
|
Thanks Mike. Zak Burke does this story duplicate the stories in your TC backlog to investigate the minimal modules needed for deployment? Or is this something different? |
| Comment by Zak Burke [ 05/Jul/22 ] |
|
Khalilah Gambrell, "duplicates a story" is not quite accurate, but
|
| Comment by Jakub Skoczen [ 06/Jul/22 ] |
|
Moved the FOLIO DevOps backlog and blocked on
|
| Comment by Khalilah Gambrell [ 06/Jul/22 ] |
|
Thanks Zak Burke and Jakub Skoczen |
| Comment by Jakub Skoczen [ 17/Oct/22 ] |
|
Zak Burke Steve Ellis Craig McNally Guys, is there a ticket/epic for the work to provide platform-minimal. We're not sure if this item can proceed at this point. |
| Comment by Craig McNally [ 17/Oct/22 ] |
|
I just added a link... I think this is blocked by https://folio-org.atlassian.net/browse/FOLIO-3548
|
| Comment by Steve Ellis [ 17/Oct/22 ] |
|
Craig McNally and Jakub Skoczen - I closed
|
| Comment by Mike Taylor [ 24/Oct/22 ] |
|
What, concretely, prevents us from proceeding with this? I don't see anything in
|
| Comment by Steve Ellis [ 26/Oct/22 ] |
|
Mike Taylor - There is nothing stopping implementing the minimal platform in vagrant. The min platform works. Vagrant would make it easy to fire up a backend to develop against for front end work. If something could be done to make it easier to inject module code changes into the vagrant env... that would make it something even more useful when testing out new backend module code in an "integrated" way – without the need to install everything. |
| Comment by Mike Taylor [ 26/Oct/22 ] |
|
That's good, Steve Ellis. Then perhaps the only thing holding us up here is getting some of Wayne Schneider's time allocated to build the box. Wayne, do you have a rough sense of how long you think it might take you? ... And of course "something could be done to make it easier to inject module code changes into the vagrant env" is exactly what I have been working on with folioctl! |
| Comment by Jakub Skoczen [ 31/Oct/22 ] |
|
Thanks Steve Ellis. We would like to consider this for next sprint – is there something that Wayne Schneider needs to know to proceed with this item? |
| Comment by Steve Ellis [ 31/Oct/22 ] |
|
Jakub Skoczen - No nothing special that Wayne Schneider needs to know as far as getting the minimal platform to work. Basically mod-users-bl is (if you build from master) much more forgiving. Prior to the change here https://github.com/folio-org/mod-users-bl/pull/148 okapi would complain unless you installed all of mod-users-bl's dependencies. But now the modules that used to cause the cascade of dependencies have been made optional. The "core" features of mod-users-bl still work. You can login and get a CompositeUser object back. Other endpoints degrade gracefully, such as the ones that rely on notify. See the PR above for details. Wayne Schneider I think it would be most useful if the vagrant had search and kafka installed, even though the core modules don't use them. That way a dev could easily drop in new modules (perhaps with Mike Taylor's new tools) without having to configure them. But that's all backend stuff. I think Zak Burke might have some thoughts on what the stripes bundle might look like in this env. Can/should it be built for all modules regardless if they are installed on the backend? Should it be included at all or is that something which a front end dev could easily do based on what they are working on? |
| Comment by Zak Burke [ 01/Nov/22 ] |
|
Steve Ellis, the only UI modules I would expect to see in the stripes bundle from the @folio namespace are @folio/stripes and @folio/users. Practically speaking as a UI developer, I don't care what it contains because I'm never going to use it; instead, I'm going to build my own UI and use the Vagrant box only for its Okapi modules, never its UI modules. I don't know if/how other users would use the vagrant box's UI. |
| Comment by Mike Taylor [ 01/Nov/22 ] |
|
I agree 100% with Zak. |
| Comment by Steve Ellis [ 01/Nov/22 ] |
|
Zak Burke if a frontend dev is always going to make his or her own frontend bundle then to keep things simple we should probably not include any stripes stuff at all. I can't see why someone would want to have a frontend just to login with. That's easy enough to accomplish with curl etc. |
| Comment by Mike Taylor [ 01/Nov/22 ] |
|
I guess that makes sense. |
| Comment by Marc Johnson [ 03/Nov/22 ] |
My understanding was that the scope / purpose of platform minimal was to provide a running system with a UI where someone could log in. Did I misunderstand the scope of what platform minimal is? |
| Comment by Craig McNally [ 29/Nov/22 ] |
That's my understanding as well. Can someone clarify if this is still blocked, or if the status just hasn't been updated, or if it's blocked until some of the things discussed in the comments section have been sorted out? |
| Comment by Wayne Schneider [ 29/Nov/22 ] |
|
I agree that this is not blocked, and that Marc Johnson's and Craig McNally's understanding is how we will proceed. Sorry for the confusion around the status of the ticket. This work is scheduled for this sprint (next 2 weeks). Thanks, all! |