Re: [VOTE] Release Apache CloudStack Terraform Provider v0.4.0

[Pearl d'Silva]

+1

Did some basic lifecycle operations on a VM, network - such as creation, update 
and destroy, adding secondary IP to a VM.
Performed the operations as an admin and a user.
Did similar operations in a project as a user. Also attempted resetting the VMs 
SSH key.
Encountered a small issue with respect to adding a secondary IP to a NIC for a 
VM deployed in a project, but I wouldn't categorize it as a blocker and can be 
addressed in the next release.


Thanks,
Pearl


From: Daan Hoogland 
Sent: Friday, January 28, 2022 9:29 PM
To: dev 
Cc: users@cloudstack.apache.org 
Subject: Re: [VOTE] Release Apache CloudStack Terraform Provider v0.4.0

+1 (binding)

performed similar tests as Rohit but in a dual zone and with a vpc in one
of the zones. Two different configurations one with one zone and one with
both. destroy went fine ;) in the vpc firewall rules would not create. I am
not sure this is a known issue, but the error message is clear, so I'm not
calling it a bug:

"Unable to create firewall rule for the IP address ID=204 as IP is not
associated with any network and no networkId is passed in"

The only weird thing is that the network is not an allowed parameter.


On Fri, Jan 28, 2022 at 9:55 AM Rohit Yadav 
wrote:

> +1 (binding)
>
> I checked the source tarball checksum and gpg signature, and using the RC1
> build was able to test a simple VM deployment in a zone in an isolated
> network with some firewall rules applied, against a KVM based ACS 4.16.0.0
> env.
>
> (note: in my testing, in the first run the firewall application met with
> some failure but on second try of terraform apply it worked, see run log
> below)
>
> Source tarball verification:
> gpg: Signature made Wed Jan 19 15:33:18 2022 IST
> gpg:using RSA key 1031D6946F8A7C4B0C3E9EEFAEA5313845ADC482
> gpg: Good signature from "Harikrishna Patnala (github gpg) <
> harikrishna.patn...@gmail.com>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 1031 D694 6F8A 7C4B 0C3E  9EEF AEA5 3138 45AD C482
>
> Run log for reference:
>
> # terraform apply
>
> Terraform used the selected providers to generate the following execution
> plan. Resource actions are indicated with the
> following symbols:
>   + create
>
> Terraform will perform the following actions:
>
>   # cloudstack_egress_firewall.default will be created
>   + resource "cloudstack_egress_firewall" "default" {
>   + id  = (known after apply)
>   + managed = false
>   + network_id  = (known after apply)
>   + parallelism = 2
>
>   + rule {
>   + cidr_list = [
>   + "10.200.0.0/24",
> ]
>   + icmp_code = (known after apply)
>   + icmp_type = (known after apply)
>   + ports = [
>   + "21",
>   + "22",
>   + "443",
>   + "80",
> ]
>   + protocol  = "tcp"
>   + uuids = (known after apply)
> }
> }
>
>   # cloudstack_firewall.default will be created
>   + resource "cloudstack_firewall" "default" {
>   + id= (known after apply)
>   + ip_address_id = (known after apply)
>   + managed   = false
>   + parallelism   = 2
>
>   + rule {
>   + cidr_list = [
>   + "0.0.0.0/0",
> ]
>   + icmp_code = (known after apply)
>   + icmp_type = (known after apply)
>   + ports = [
>   + "22",
>   + "443",
>   + "80",
> ]
>   + protocol  = "tcp"
>   + uuids = (known after apply)
> }
> }
>
>   # cloudstack_instance.web will be created
>   + resource "cloudstack_instance" "web" {
>   + display_name = "VM1Test"
>   + expunge  = true
>   + group= (known after apply)
>   + id   = (known after apply)
>   + ip_address   = (known after apply)
>   + name = "VM1Test"
>   + network_id   = (known after apply)
>   + project  = (known after apply)
>   + root_disk_size   = (known after apply)
>   + service_offering = "688de728-5d70-42b5-9913-someID"
>   + start_vm = true
>   + tags = (known after apply)
>   + template = "someID-1d5b-4335-a9e7-someID"
>   + zone = "someID-cf47-4b0b-8cf0-someID"
> }
>
>   # cloudstack_ipaddress.newIP1 will be created
>   + resource "cloudstack_ipaddress" "newIP1" {
>   + id= (known after apply)
>   + ip_address= (known after apply)
>   + is_portable   = false
>   + is_source_nat = (known after apply)
>   + network_id= (known after apply)
>   + project   = (known after apply)
>   + tags  = (known after apply)
> }
>
>   # cloudstack_ipaddress.ne

Re: [DISCUSS] Log4j migration

[Rohit Yadav]

All,

Given there are no objections or other thoughts discussed on the thread, I 
propose the following:

  *   Short-term: switch to reload4j which is a drop-in replacement and has 
published a few releases since last two weeks (seems active), this will require 
less effort for the benefit of updates/fixes that we'll get immediately.

  *   Long-term: refactor the logging usage across codebase with a utility 
wrapper (in cloud-utils) where the logging library can be replaced with 
something like logback (which seems more mature and maintained). The long-term 
option can be discussed after we move to the drop-in replacement and it turns 
out to be not maintained or has issues.

I've started a WIP PR draft for the short-term solution 
https://github.com/apache/cloudstack/pull/5878



Regards.


From: Daan Hoogland 
Sent: Wednesday, January 19, 2022 18:23
To: dev 
Cc: users@cloudstack.apache.org 
Subject: Re: [DISCUSS] Log4j migration

As I was involved it shouldn't come as a surprise to anyone that I agree
with Rohit on all he says here.
There was one consideration that we (both) abandoned quite early on; making
a pluggable framework for logging in which one can add their own preferred
library. We do not think it is worth the effort, but as a GSoC project or
if someone is willing to sponsor that it can still be put back on the table.
I have a slight preference for the wrapper solution but am open to any
input from everyone.

On Wed, Jan 19, 2022 at 1:17 PM Rohit Yadav 
wrote:

> All,
>
> Following log4jshell advisory [1], I want to start a discussion thread
> around what next steps should we follow.
>
> Overview: The log4j 1.x has limited feature set and didn't have the same
> attack surface as log4j 2.x, this saved the ACS community from log4jshell
> [1]. In addition, our uber/fat jar build process since (last few years)
> only bundles classes from dependency jars that CloudStack management server
> codebase requires; this may benefit that certain classes which could be
> exploit-able in 1.x weren't actually shadowed/bundled in the
> cloudstack-management uber/fat jar[2]. This strategy reduces the CloudStack
> management uber/far jar's attack surface greatly.
>
> What is used in CloudStack: (details investigated with my colleague Daan)
>
>   *   Basic logging feature (console/file/rsyslog appenders, log levels,
> log4j config file)
>   *   Context-aware logging (this includes full/abbreviated class/package
> name, and sometimes specific context,
>
> LogContext and CallContext have some example use of MDC, NDC)
>
>   *   Stacktrace upon exception, a custom CglibThrowableRenderer class
>   *   Jar dependencies used: log4j v1.2.17, and apache-log4j-extras v1.2.17
>
> As the next step, I think it would be better to refactor the logging usage
> to a new loggging utility in cloud-utils which can be used throughout the
> codebase, and this utility can in-turn wrap whatever logging library we use
> and reduce our dependency on any logging library/version and swiftly change
> logging library. The utility may also allow us to centrally add custom
> cloudstack feature (such as context-aware logging, manage stacktrace output
> etc).
>
> I did some research to look at possible options for the community:
>
>   1.  Status-Quo, stick with log4j 1.x: this is not ideal, as v1.2.17 was
> the last release in 1.x which has reach EOL [3].
>   2.  Migrate to 2.x: this is probably what is advised by the Apache
> Logging PMC [4] since 1.x has EOL, however:
>  *   1.x pretty much sufficed our requirements of a logging library
> and 2.x has a large attack surface.
>  *
>  *   Other Apache projects (such as hadoop, hive etc) are facing while
> migrating their large codebases to log4j 2.x; the migration will require
> time, effort, and testing. The 2.x migration guide would require a lot of
> manual effort, there is no tooling to do this at scale.
>  *   On Twitter, some of the Logging PMC have advised that their v3
> architecture will make log4j modular and lower attach surfaces.
>  *   My opinion: Logging library shouldn't try to do anything beyond
> logging, I'm less confident in migrating to 2.x after seeing how the CVE
> was handled by the Logging PMC and I didn't have a good interaction with
> them in a ML discussion thread. For an ASF TLP that is asked to adhere to
> the 'community over code' spirit, the user community isn't listend to and
> in a ML thread, it was deemed that any 1.x fork/maintenance would be
> considered "hostile" - this has led to interested sponsors and PMCs of
> other Apache projects joining forces with Ceki to continue log4j 1.x fork
> outside of ASF (see below).
>   3.  Migrate to 1.x fork, drop-in replacement: Ceki (one of the
> developers of log4j 1.x, also behind sl4j and logback) has started a fork
> of 1.x under the name reload4j with which they continue 1.x support and
> address bugs/CVEs. They have already published v1.2.18
> https://github.com/qo