ctubbsii commented on a change in pull request #420: URL: https://github.com/apache/fluo-muchos/pull/420#discussion_r770774851
########## File path: ansible/roles/azure/files/cloud-init.yml ########## @@ -0,0 +1,23 @@ +#cloud-config +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +# +# NOTE: do not modify the first line in this file - it is a mandatory +# header to designate the contents as a cloud-init configuration +# +# Upgrade the instance on first boot: +package_upgrade: true Review comment: > This PR is conditional to Azure cluster launches and is a must-have, I don't think the basis of my previous thoughts were specifically about whether it would apply outside the limited scope of the Azure cluster, but that the idea itself implies that a user consciously configures an out-of-date image, and then has to deal with the wait time to bring it up-to-date, when a much more elegant solution is to just use an up-to-date image from the start. You say it's a "must-have", but for whom? The problem can be solved in several ways, not the least of which is to change the default to use something newer than an OS initially composed way back in 2013. > as there are no other more recent updated CentOS 7.x images on Azure. That seems easily fixable... or avoidable. Why does the default have to be CentOS 7? Why not CentOS 8, CentOS Stream 8 or 9, or Fedora 35, or RHEL 8? The problem of no more recent updated "official" CentOS 7 images seems like a problem only if we make it a problem. > Building a custom patched image and using it for Muchos is time-consuming and not everyone may know how to do that, either. Nobody expects everyone to do that. I'm not sure how it works on Azure, but on EC2, community images are shared for everybody to reuse, so it only needs to be done once for many people to benefit from it. I'd be surprised if there weren't already multiple updated CentOS 7 community images available on Azure, unless Azure just doesn't support that. But, even that's not necessary. A different OS, a newer OS, is also a possible solution. If we keep patching to force an 8 year old CentOS 7 to keep working, rather than change the default image to something newer, so that we default to testing on newer operating systems likely to be used in future Accumulo and Fluo deployments, then I think we're solving the problem wrong. > There is no 'mischievous' intent here - this fix is scoped to address the specific problem for Azure based deployments. Perhaps that word isn't the right one. I don't believe this is nefarious, deceptive, or anything like that. The description was clear about the intent behind the proposed change and I did not mean to imply otherwise. "Mischievous" seemed like a more "playful" term to use, since the PR seemed like it was tip-toeing around the previous discussions rather than directly addressing them. I did not mean any offense by my use of that word, but I am sorry if I caused any. -- 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 the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
