[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: PNG File Screen Shot 2019-02-25 at 11.25.27.png    
Issue links:
Blocks
blocks MODUSERBL-153 leverage optional okapi dependencies ... Closed
is blocked by FOLIO-3253 SPIKE - Investigate minimal FOLIO pla... Closed
is blocked by FOLIO-3548 Verify and fix platform-minimal Closed
is blocked by FOLIO-3625 Configure platform-minimal similar to... Closed
Relates
relates to FOLIO-1632 Create lighter-weight folio core VM Closed
relates to STCLI-15 Dynamic Okapi module installation Closed
relates to STCLI-114 CLI support for local backend modules Closed
relates to FOLIO-3337 Replace use of release-core at Tutori... Blocked
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 ]

I wonder how easy it would be to generate a visual dependency DAG of all the modules?

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:
http://localhost:9130/_/proxy/modules?dot=true&latest=1&preRelease=false

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 FOLIO-3253 Closed covers the same ground and I think once we have the UI stories attached to that one completed, then somebody in devops can usefully pick up this one. In short, I agree with Mike that this should stay open, perhaps blocked on FOLIO-3253 Closed

Comment by Jakub Skoczen [ 06/Jul/22 ]

Moved the FOLIO DevOps backlog and blocked on FOLIO-3253 Closed . This issue should not be closed.

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 FOLIO-3548 Closed . I'm confident that proceeding to the next phase of actually making use of the minimal platform in various contexts is something we can do. One useful thing might be to create a vagrant box.

Comment by Mike Taylor [ 24/Oct/22 ]

What, concretely, prevents us from proceeding with this? I don't see anything in FOLIO-3548 Closed that needs to be done.

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 ]

Steve Ellis

I can't see why someone would want to have a frontend just to login with.

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 ]

My understanding was that the scope / purpose of platform minimal was to provide a running system with a UI where someone could log in.

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!

Generated at Thu Feb 08 23:15:29 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.