davidjumani commented on PR #41:
URL:
https://github.com/apache/cloudstack-kubernetes-provider/pull/41#issuecomment-1420574877
My bad @rohityadavcloud I had tested this myself and verified the fix
--
This is an automated message from the Apache Git Service.
To respond to the message, plea
rohityadavcloud closed pull request #302: Update
choosing_deployment_architecture.rst
URL: https://github.com/apache/cloudstack-documentation/pull/302
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
Thanks Daniel, that approach looks nice to me.
How would it work in case a view needs to be removed? I would think we can
remove the file from the views directory and add the drop view SQL on the
schema file.
Regards,
Nicolas Vazquez
From: Daniel Augusto Veronez
Nicolas,
I had not thought about this case. I think your suggestion is nice; we can
use this approach.
Best regards,
Daniel Salvador (gutoveronezi)
On Tue, Feb 7, 2023 at 9:45 AM Nicolas Vazquez <
nicolas.vazq...@shapeblue.com> wrote:
> Thanks Daniel, that approach looks nice to me.
>
> How wou
nice guys, i think we should go with it. Less error prone than our current
MO
On Tue, Feb 7, 2023 at 2:13 PM Daniel Salvador
wrote:
> Nicolas,
>
> I had not thought about this case. I think your suggestion is nice; we can
> use this approach.
>
> Best regards,
> Daniel Salvador (gutoveronezi)
>
That's a good idea but would create two ways of applying SQL changes during
upgrade. Nicolas's point where removal is needed may be handled by just a drop
statement in the views sql file.
The other issue I see is lack of some kind of enforcement, validation, or check
(it may be possible to do t
