Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Jason Frey
@Fryguy
active_record-id regions gem still has references to it
I think we kept it for backward compat, but region is determined now by looking at the sequence on an existing table
https://github.com/ManageIQ/activerecord-id_regions/blob/master/lib/active_record/id_regions.rb#L135-L141
ManageIQ/manageiq#6248 :wink:
Keenan Brock
@kbrock
the use case we have is when setting up a database. you need to specify the region via the environment during the first migration ever run
but then never again. we added options of passing that in as an env variable or a —region - your choice. But some rake tasks and legacy rails console code wanted to use the file instead of passing those env variables / arg
not sure what has happened here over the past 4ish years
Jason Frey
@Fryguy
for podified, that's handled via an actual env var
Keenan Brock
@kbrock
perfect
Jason Frey
@Fryguy
I thought appliance console handled it on appliances
Keenan Brock
@kbrock
just remember having heated discussions on how the appliance console could use env vars and/or args vs the file. don’t remember the end result nor remember if/when we did something
Jason Frey
@Fryguy
it's managed here - https://github.com/ManageIQ/manageiq-appliance-build/blob/master/kickstarts/partials/post/appliance_init.ks.erb#L8
(on that note, no idea why that line is in there twice)
we decided on CLI option it seems
oh seems JoeV duplicated that line accidentally
Keenan Brock
@kbrock
no. in the appliance console itself. when the user says “lets do region 999”
Jason Frey
@Fryguy
yeah, I assume any CLI option also has a menu option
Keenan Brock
@kbrock
https://github.com/ManageIQ/activerecord-id_regions/blob/master/lib/active_record/id_regions.rb#L136
Jason Frey
@Fryguy
ok, fixed the duplicate init at least :) ManageIQ/manageiq-appliance-build#477
Keenan Brock
@kbrock
^ we wanted to be doubly certain
Jason Frey
@Fryguy
@kbrock yeah...so the file is completely optional
otherwise, we check env var (for initial migration), otherwise we just use the sequence
Keenan Brock
@kbrock
yup, aware. I made that logic tree
then spent 2? years trying to delete that bugger. frustrating that it is still around. kinda like mice in the attic
Jason Frey
@Fryguy
I'm fairly certain nothing actually creates that file, but check the appliance console to be sure
Keenan Brock
@kbrock
:+1:
Jason Frey
@Fryguy
If it's not there, I don't see why we can't remove that line in activerecord-id_regions (though it's technically not doing anything if nothing creates the file aynway :wink: )
Keenan Brock
@kbrock
region file is in quite a few places still. (including docs)
Jason Frey
@Fryguy
:+1:
put together an issue with links, and we can discuss, but we likely can kill it / do it with ENV vars
Keenan Brock
@kbrock
yea, this will stay as a rant for a little longer…
  desc "Write a remote region id to this server's REGION file"
  task :join_region => :environment do
    configured_region = ApplicationRecord.region_number_from_sequence.to_i
    EvmApplication.set_region_file(Rails.root.join("REGION"), configured_region)
  end
Jason Frey
@Fryguy
happy you are detangling :)
Keenan Brock
@kbrock
nah - that is a tangent from my main goal. killing the watch dog. I sure have a vengence towards some of our code.
Jason Frey
@Fryguy
haha...nothing wrong with that :wink:
Keenan Brock
@kbrock
:)
Michael Butak
@mikebutak
@pemcg I'm told we will have about 1000 users, probably 200-300 max concurrent users.
Something tells me that our two app servers (32 GB RAM each) would not be sufficient.
Joe Rafaniello
@jrafanie
Will all of those users be logging into and using the UI? Will they be using the API instead?
Jason Frey
@Fryguy
...simultaneously?
Joe Rafaniello
@jrafanie
Will they all be running intensive tasks such as provisioning?
if their main interactions will be against apache (UI or web services/api), then the number of UI and web service worker/pods are likely the bottleneck... if their interactions cause lots of backend work (automate / provisioning / various queueing), that backend work could be the bottleneck
Jason Frey
@Fryguy
You can crank up the number of UI workers to deal with the load and/or add more servers - in some of the really big production deployments, I've seen people have 2-5 dedicated servers for UI (of course, sometimes that includes HA-standby servers)
Joe Rafaniello
@jrafanie
@mikebutak can you roll it out to users in stages so you can evaluate the load?
without knowing what resources the users will consume, it's hard to predict where you'll need to monitor for resource starvation
Jason Frey
@Fryguy
We have some information in the Deployment Planning Guide, btw - https://www.manageiq.org/docs/reference/latest/deployment_planning_guide/index.html
Michael Butak
@mikebutak
This message was deleted

will all of those users be logging into and using the UI? Will they be using the API instead?

Logging in and using the UI, not the API.

simultaneously?

Definitely not. In fact, I think of the 1000 users granted access some will rarely use it. Maybe 20% will use it regularly. Management guessed 20-30% concurrent users. Maybe on day 1, but I think that's high.

Will they be running intensive tasks such as provisioning?

yes

an you roll it out to users in stages so you can evaluate the load?

I could suggest that.

We have some information in the Deployment Planning Guide...

Thanks, that looks really helpful.

Actually I can ask our virtualization admins about concurrent users with our current vmware tool.
Michael Butak
@mikebutak
LOL I just spoke with our virtualization admins. The number of concurrent users in our current tool (VRA) is minuscule. I'll take a look at the docs for future enhancements, but for the initial release I think we're good. Thanks everyone!
Jason Frey
@Fryguy
:+1: