Closed GuilhermeFAC closed 4 months ago
Hi @GuilhermeFAC so these two features should be also available already in ansible-devops... when calling suite_app_config
while installing Manage, you can provide the following parameters:
export MAS_APP_SETTINGS_SERVER_BUNDLES_SIZE="snojms" # This server bundle flavor deploys only all + jms pods
export MAS_APP_SETTINGS_DEFAULT_JMS="true" # This should enable both cqin and cqout queues. By default it is set to `false`
If you want to have a preview test, you can install MAS/Manage using this cli version 7.18.0-pre.manage-additional-settings
As in:
docker run -v $HOME:/tmp -ti --rm --pull always quay.io/ibmmas/cli:7.18.0-pre.manage-additional-settings
Any feedbacks are welcome!
Here's how it should look like with 7.18.0-pre.manage-additional-settings
Very good @andrercm , exactly the way I imagined, it makes it a lot easier. If you test it, I'll give you feedback.
Hi @andrercm
and the ingress is ok in the cluster
@GuilhermeFAC is this an IBM Cloud cluster?
Yes @andrercm
interesting... in my IBM Cloud env, this issue does not happen... can you pull the cli image again? I added some debugs in this task to understand what's happening:
docker run -v $HOME:/tmp -ti --rm --pull always quay.io/ibmmas/cli:7.18.0-pre.manage-additional-settings
If you can provide me the debug logs from the next time you execute that would help assess the issue.
What logs? I rerun Docker and return the same error itconsol-install-j7l7n-pre-install-check-pod-step-ocp-verify.log
From your logs it does not seems you're running the latest 7.18.0-pre.manage-additional-settings
version... i added some debug to that... can you go to your openshift and find namespace mas-$MAS_INSTANCE_ID-pipelines
and then Workload > Deployments > mas-cli > YAML tab and set imagePullPolicy: Always
then save... It should force the 7.18.0-pre.manage-additional-settings
image to be pulled as a new image then hopefully it will pick the latest... then rerun the pipeline again.
I did that and now it's gone and there's no error hahaha... I don't know what happened.
ok... so i added a potential fix to that in a hope that it fixes it... so cool it did fix it :)
Finally, I see if the installation occurred as defined in the parameters
can you go to Parameters tab and see if you can find some parameters values for the following:
mas_app_settings_base_lang
mas_app_settings_secondary_langs
mas_app_settings_server_bundle_size
mas_app_setting_default_jms
mas_app_setting_server_timezone
db2_type
db2_timezone
@andrercm about the timezone in the db2u pod, he defined the property but the server continues with UTC time:
For the server to stay in the chosen zone, it is necessary to add a variable in StatefulSets -> db2u -> Environment
TZ -
This will create a new pod of the db2u instance and the server will have the timezone applied correctly.
Oh... so the timezone
property in the DB2UCluster
server for nothing?
I believe that in addition to the property in Db2cluster there must also be this "TZ", but I can't say if only the TZ would solve it, because if you look at the jvm pod or the maxinst pod there is also this TZ in the environment, when We define the timezone through the manage workspace and it adds it to maxinst. I believe there is something missing when we define it in Db2ucluster that should also add this TZ.
Just to update, I installed the maximum with db2oltp database, jms (continuous queue enabled) + pod all, added base language EN + PR-BR and the manage Brazil/East timezone. It went up without any problems and with everything configured. Very good thank you.
This is the only detail left from TZ to db2 in environment
So it seems setting the advsOpt.timezone
is really the only thing needed to set it during DB2 instantiation...
https://www.ibm.com/docs/en/cloud-paks/cp-data/4.8.x?topic=administering-setting-timezone-new-existing-deployments
Can you test the two approaches described in this doc and let me know if any works for you? Ideally we would need to have an option that could be set in both ManageWorkspace and DB2 using the same parameter value. i.e both db2_timezone
and mas_app_settings_server_timezone
set to the same value to simplify the process.
So @andrercm , I followed this IBM document when I did the manual, but what I told you happened, even though there in the log it shows that the timezone is defined and even restarting the db2u pod it does not change the server's timezone, I have already suggested that IBM correct it this document because it only worked when I added this TZ variable to the environment. So both can be managed with db2, but you need to add this TZ variable to db2u to actually change the timezone on the server, in that pod.
Does it work if i set TZ=GMT
(using timezone code instead of city) for example?
Asking this since ManageWorkspace timezone uses timezone code so we could use same value for both..
In TZ if you enter a valid value it works, In Mascli I defined Brazil/East.
The same timezone values in ManageWorkspace can be used to define the db2u TZ. For example, the list has Brazil/East, America/Sao Paulo, so whatever is defined in ManageWorkspace can also be defined in the TZ of the db2u pod.
That's good... ok, so there seems to need an extra step to set the db2 statefulset with this env var... i'll do some research to see if there's another way to set it upfront in the db2ucluster, it would be better idea than waiting for db2 to be created then setting the var afterwards. If there's a way to set this while the db2 is being created that would safe lot of time.
A tip is to see how it is done for Manage, as it has already defined this 'TZ' variable in the environment in the JVM pods and in maxinst when we choose a timezone in the manageworkspace
@andrercm the tz on the Manageworkspace CR only controls the timezone of the application server, not the database's timezone as database creation and maintenance is not part of Manage operator's responsibility at this point. The cli/ansible will need to populate db2ucluter's timezone when taking the same timezone in manage installation. Also, the db2u timezone functionality only works after the one coming with CPD 4.7.3, or 11.5.8.0-cn5.
Thanks for clarifying this @wangqymro ... in our case, mas cli does not use DB2 on top of CPD... it uses DB2 standalone currently at s11.5.9.0-cn1 version.
@GuilhermeFAC
Coming back to this, I have made changes that sets the TZ
variable in DB2 statefulset as described here
So db2u pod now can be set:
The changes are included in this cli version 8.1.0-pre.manage-additional-settings
Can you check if this version contains everything you are expecting? I'll be waiting your feedback to promote these changes.
Ok @andrercm , I'll do a new installation to test this change!
@GuilhermeFAC thanks! let me know how that goes and if any adjustments are needed.
@andrercm Good afternoon, I instaled using 8.1.0-pre.manage-additional-settings but the varible TZ was not placed in the db2 statefulset
@GuilhermeFAC can you provide me logs from the db2
task?
Also make sure you're running the latest version of 8.1.0-pre.manage-additional-settings
Can you go to your openshift and find namespace mas-$MAS_INSTANCE_ID-pipelines and then Workload > Deployments > mas-cli > YAML tab and set imagePullPolicy: Always then save... It should force the 8.1.0-pre.manage-additional-settings
image to be pulled as a new image then hopefully it will pick the latest... then rerun the pipeline again.
install-egv6q7-db2-manage-pod-step-db2.log
Allrigth , I am going to try
@GuilhermeFAC i found the problem... the code was not finding the right db2 pod to add the timezone var... it was finding the db2-etcd pod...
TASK [ibm.mas_devops.db2 : Set timezone variable in db2u statefulset] **********
changed: [localhost] => changed=true
cmd: oc set env sts c-mas-cp4upgrade-main-manage-etcd TZ=UTC -n db2u
delta: '0:00:00.388820'
end: '2024-04-12 21:47:56.030679'
msg: ''
rc: 0
start: '2024-04-12 21:47:55.641859'
stderr: ''
stderr_lines: <omitted>
stdout: statefulset.apps/c-mas-cp4upgrade-main-manage-etcd updated
stdout_lines: <omitted>
TASK [ibm.mas_devops.db2 : debug] **********************************************
ok: [localhost] =>
db2_set_timezone_output.stdout_lines:
- statefulset.apps/c-mas-cp4upgrade-main-manage-etcd updated
TASK [ibm.mas_devops.db2 : debug] **********************************************
I fixed the problem, it should be available now in 8.1.0-pre.manage-additional-settings
Hi @andrercm .
I did the procedure you asked me to do and rerun the pipeline and now it has defined the TZ variable in the statefullset.
Great news @GuilhermeFAC ... is there any other feedback you want to highlight? Or are all the implementations you expected contained at this point?
At the moment the most necessary ones are implemented, it looks very good, Thank you.
I have a suggestion but it is for the storage issue, being able to select the type of storage per project, for example, in db2 select file and block gold(10 iops), for prometheus select bronze(2 iops), pvc for doclinks bronze(2iops) ), being able to choose a project that uses separate PVC, as not everything needs 10 Iops. but this point must be more complicated for you. But if possible it would be cool.
Those are good feedbacks @GuilhermeFAC
I think some of that might be accomplished currently using the ansible-devops collection directly, but they might but be backported/supported in MAS cli yet. In MAS CLI, the current approach is to defined one specific type for file and another type for block storage and reuse that across the install pipeline where needed.
Feel free to open an issue for this customization in the CLI repo to a future enhancement: https://github.com/ibm-mas/cli
As to the scope of improvements that we have worked together, I'll close the current issue as everything has been validated on your side! Thanks a lot for your help, hopefully pretty soon these changes will be merged and released in the MAS CLI. In meanwhile you can keep using the beta version provided.
@andrercm Good afternoon, see the possibility of improvement by selecting the option to install jms server when installing manage.
1 - Make the jms go up by enabling the cqin and cqout queues by default (cqout only available in 8.11) following document: https://www.ibm.com/support/pages/node/6962441
2 - Today, when choosing to install jms using mascli, maange goes up with separate report, ui, integration bundles, see the possibility of adding an option to upload jms + pod "all" only.