jrafanie

Improve development, testing, and workflow:

• Test with config/puma.rb with lower thread count since we have less cores in github actions
• Add cypress-grep or similar to be able to tag tests and run them individually by tag (smoketest, simulate_worker, db_mutate)
  • The last tag, db_mutate, could help us track tests that mutate the database so we can eventually move to using something like cypress-rails to rollback changes done in the test automatically.
• Provide more interfaces for automatically starting dependent processes
  • bundle exec rake spec:cypress - automatically expands rate limit, starts our rails server, starts a simulated worker process, etc.
  • yarn cypress:open - doesn't do any of that... you have to do this yourself
  • yarn cypress:run:chrome - same as above...
• We should automatically start with CYPRESS=true from these or make it clear so devs know to use that to run without miq_debug notifications and slow code reloading.

jrafanie

# This script will generate a generic object based on a previously created
# generic object definition.  This generic object definition has a services attribute of type "string".
# Based on API usage found here: https://www.manageiq.org/docs/reference/latest/api/reference/generic_objects.html#generic-objects
# This can be wrapped into usage into existing services by utilizing generic objects in services through automate or ansible.
# See: https://manageiq.gitbook.io/mastering-cloudforms-automation-addendum/generic_objects
definition_id = 13

require 'json'
require 'faraday'

jrafanie

# This gem with my changes can be found here: https://github.com/ManageIQ/manageiq-decorators/compare/master...jrafanie:manageiq-decorators:zeitwerk

joerafaniello@Joes-MacBook-Pro-2 manageiq-decorators % tree lib
lib
├── manageiq
│   ├── decorators
│   │   ├── engine.rb
│   │   └── version.rb
│   └── decorators.rb
├── manageiq-decorators.rb

jrafanie

1. Determine your data directory:

psql -U root vmdb_development -c "show data_directory;"

2. Edit: DATA_DIRECTORY_FROM_STEP1/pg_hba.conf

Ensure this line is added:

local replication all trust

jrafanie

Summary:

One would expect the before and after checkout callback would wrap checkout or the undlying code that creates a new adapter and assigns it to a pool or assigns an existing one from the pool. The before and after checkout callback actually wraps verify.

Note, the behavior is the same in 5.1.x, 5.2.x, 6.0.x, 6.1.x but the code snippets come from: https://github.com/rails/rails/blob/v6.0.4/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb

Therefore, there is no way to instrument diagnostic code BEFORE the actual checkout occurs.

jrafanie

On my fyre infra node, I noticed there was already an nfs PV for the registry storage and I couldn’t figure out how to export a new nfs properly so I just copied it.

[root@jrafanie-inf data]# cat ~/image-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: registry-storage
spec:
  capacity:
    storage: 200Gi

jrafanie

* Install go

brew install [email protected]
echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> ~/.zshrc
export PATH="/usr/local/opt/[email protected]/bin:$PATH"
go version

* Install the operator-sdk:
(Note, redhat laptop is using operator-sdk 0.19.3, go, 1.13 and bin/build works but the operator-sdk generate commands were not tested)

jrafanie

irb(main):021:0> MiqWorker.descendants.each {|w| puts "Class: #{w.name.ljust(80)} Deployment: #{w.new.worker_deployment_name.ljust(50)} Advanced settings: #{w.path_to_my_worker_settings}"}; nil

Class: MiqUiWorker                                                                      Deployment: 1-ui                                               Advanced settings: [:worker_base, :ui_worker]
Class: MiqQueueWorkerBase                                                               Deployment: 1-queue-worker-base                                Advanced settings: [:worker_base, :queue_worker_base]
Class: MiqCockpitWsWorker                                                               Deployment: 1-cockpit-ws                                       Advanced settings: [:worker_base, :cockpit_ws_worker]
Class: MiqRemoteConsoleWorker                                                           Deployment: 1-remote-console                                   Advanced settings: [:worker_base, :remote_console_worker]
Class: MiqSch

jrafanie

How to setup replication in pods with postgresql 12 (very similar to 10):

1) Do the following steps for each region: example: 99 for global, 1 for region
In your local manageiq-pods repo, modify the deploy/crds/manageiq.org_v1alpha1_manageiq_cr.yaml with this information:

...
spec:
  applicationDomain: <unique name>
  postgresqlImageName: <user/repository_of_pg_12_image such as 'jrafanie/postgresql'>
  postgresqlImageTag: <tag such as 'latest'>

jrafanie

Thread.abort_on_exception = true
STDOUT.sync = true
STDERR.sync = true

module DeploymentCheck
  def watch_pod_options
    {
    :label_selector   => "app=manageiq",
    :namespace        => my_namespace,
    # :label_selector => "app=manageiq,worker=true"