[GitHub] [cloudstack-primate] borisstoyanov opened a new issue #367: [BUG] apt install fails to cleanup some files after installation due to permissions
borisstoyanov opened a new issue #367: URL: https://github.com/apache/cloudstack-primate/issues/367 **Describe the bug** Although installation is successful there's a warning message which indicates some files could not be deleted after install due to permissions. This is quite cosmetic issue and can be ignored to sunny days :) **To Reproduce** Steps to reproduce the behavior: 1. Install primate of ubuntu as root **Expected behavior** installation succeeds without any error/warning **Management server (please complete the following information):** - OS: Ubuntu18.04 **Additional context** ``` root@ref-trl-977-v-Mu18-boris-stoyanov-mgmt1:~# apt install ./cloudstack-primate_0.5.0-20200528_all.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'cloudstack-primate' instead of './cloudstack-primate_0.5.0-20200528_all.deb' The following NEW packages will be installed: cloudstack-primate 0 upgraded, 1 newly installed, 0 to remove and 96 not upgraded. Need to get 0 B/3,674 kB of archives. After this operation, 20.9 MB of additional disk space will be used. Get:1 /root/cloudstack-primate_0.5.0-20200528_all.deb cloudstack-primate all 0.5.0-20200528 [3,674 kB] Selecting previously unselected package cloudstack-primate. (Reading database ... 106221 files and directories currently installed.) Preparing to unpack .../cloudstack-primate_0.5.0-20200528_all.deb ... Unpacking cloudstack-primate (0.5.0-20200528) ... Setting up cloudstack-primate (0.5.0-20200528) ... N: Download is performed unsandboxed as root as file '/root/cloudstack-primate_0.5.0-20200528_all.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) ``` 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [ANNOUNCE] Apache(R) CloudStack(R) Release 4.14 (LTS)
Nice job @Andrija Panic ! Thanks all ! Glad to see a new LTS release. -Wei On Tue, 26 May 2020 at 12:08, Andrija Panic wrote: > Announcing Apache® CloudStack® LTS Release 4.14 > > The Apache CloudStack project is pleased to announce the release of > CloudStack 4.14. Apache CloudStack 4.14.0.0 is a 4.14 LTS release with over > 15 major new features, and over 200 enhancements and fixes since 4.13. > Highlights include: > > - New modern UI (Project Primate, Technical preview) > - Backup and Recovery framework > - Backup and Recovery Provider for Veeam > - VM ingestion > - L2 network PVLAN enhancements > - CloudStack Kubernetes Service > - UEFI support > - KVM rolling maintenance > - Enable Direct Download for systemVM templates > - VR health checks > - Download logs and diagnostics data from SSVM/CPVM/VRs > - Enable additional configuration metadata to virtual machines > > The full list of new features can be found in the project release notes at > http://docs.cloudstack.apache.org/en/4.14.0.0/releasenotes/changes.html > > # Documentation > The 4.14.0.0 release notes include a full list of changes: > http://docs.cloudstack.apache.org/en/4.14.0.0/releasenotes/changes.html > The CloudStack documentation includes upgrade instructions from previous > versions of Apache CloudStack, and can be found at: > http://docs.cloudstack.apache.org/en/4.14.0.0/upgrading/index.html > The official installation, administration and API documentation for each of > the releases are available on our documentation page: > http://docs.cloudstack.apache.org/ > > # Downloads > The official source code for the 4.14.0.0 release can be downloaded from > our downloads page: > http://cloudstack.apache.org/downloads.html > > In addition to the official source code release, individual contributors > have also made convenience binaries available on the Apache CloudStack > download page, and can be found at: > http://download.cloudstack.org/ubuntu/dists/ > http://download.cloudstack.org/centos/7/ > http://www.shapeblue.com/packages/ > > Kind regards, > > Andrija Panić >
[GitHub] [cloudstack-primate] blueorangutan commented on pull request #330: Add unmanage VM button
blueorangutan commented on pull request #330: URL: https://github.com/apache/cloudstack-primate/pull/330#issuecomment-635182303 Packaging result: :heavy_check_mark:centos :heavy_check_mark:debian :heavy_check_mark:archive. JID-1947 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Centralised logging capability.
Hi, This is a nice idea and initiative, we have a similar project in our backlog, we cloud help to improve this PR. There is some issues to send logs to management-server: * this current feature impose use of rsyslog * support a single management server , would not work for a redundant deployment of a management-server * would require large amount of disk space if log rotate not managed properly. * a very good value added for a dev environment Like Daan is suggesting, if the log destination could be a configurable parameter, we could change the destination ip and port where to send logs to a Logstash receiver potentially so we can centralize log in another system such as an ELK cluster. On our side we want to implement log forwarding for Virtual-Routers, the idea we had in mind would be to deploy filebeat in the VR and sent their log to the hypervisor internal management network, to the hypervisor host, which would have a Port-Forwarding configure to the log destination IP. So far it's the simplest way we found it could work relatively safely without adding a new NIC to VR or interacting with customers side of the VR. We could also skip filebeat and just forward rsyslog but would need to be UDP traffic for sure to avoid impacting perf or the VR is the destination is down or experience high latency. Cheers, PL On Wed, May 27, 2020 at 12:20 PM Sven Vogel wrote: > Hi Sina, > > First. Cool feature! > > Agree with Daan. This would be absolutely nice to have the possibility to > send the log files to separate log server. So in the end of the day we have > an Heavy management server. > > Cheers > > Sven > > > __ > > Sven Vogel > Lead Cloud Solution Architect > > EWERK DIGITAL GmbH > Brühl 24, D-04109 Leipzig > P +49 341 42649 - 99 > F +49 341 42649 - 98 > s.vo...@ewerk.com > www.ewerk.com > > Geschäftsführer: > Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke > Registergericht: Leipzig HRB 9065 > > Zertifiziert nach: > ISO/IEC 27001:2013 > DIN EN ISO 9001:2015 > DIN ISO/IEC 2-1:2011 > > EWERK-Blog | LinkedIn | Xing | Twitter | Facebook > > Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. > > Disclaimer Privacy: > Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist > vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der > bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, > Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte > informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie > die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. > Vielen Dank. > > The contents of this e-mail (including any attachments) are confidential > and may be legally privileged. If you are not the intended recipient of > this e-mail, any disclosure, copying, distribution or use of its contents > is strictly prohibited, and you should please notify the sender immediately > and then delete it (including any attachments) from your system. Thank you. > > Am 27.05.2020 um 17:43 schrieb Daan Hoogland : > > > > great initiative Sina, I did leave a comment on the PR, about > > configurability. > > in short two worries: > > 1. an operator uses a different log host than the MS (i.e an ip/hostname > > config) > > 2. an operator wants to not use the feature (i.e. a boolean flag) > > I'm not sure how much this would require, but it seems minimal. Of > course, > > not opening the port is blocking the feature as well. > > > > > >> On Wed, May 27, 2020 at 3:55 PM Sina Kashipazha > >> wrote: > >> > >> > >> Centralised logging capability. > >> > >> Our improvements to systemvm allow Cloudstack administrator to access > >> systemvms logs inside the management server. It removes the difficulty > of > >> downloading logs from systemvms. They are forwarded to the management > >> server automatically, and administrators can access them in > >> "/var/log/rsyslog/%HOSTNAME%/syslog”. > >> > >> > >> It doesn’t require additional work, rsyslog setups on Cloudstack > already. > >> The only thing we have to do is open rsyslog port to receive these logs > and > >> tell hypervisors and systemvms to forward them to the management server. > >> > >> Any comments would be highly appreciated. > >> > >> For more information take a look at below issue and pull request: > >> Issue: https://github.com/apache/cloudstack/issues/4093 > >> Pull request: https://github.com/apache/cloudstack/pull/4108 < > >> https://github.com/apache/cloudstack/pull/4108> > >> > >> Kind Regards, > >> Sina > > > > > > > > -- > > Daan >
[GitHub] [cloudstack-primate] sureshanaparti commented on pull request #353: UI changes for Dynamic roles improvements
sureshanaparti commented on pull request #353: URL: https://github.com/apache/cloudstack-primate/pull/353#issuecomment-635422589 > @sureshanaparti added some comments. I've not able to test the UI yet. > For translation, @rhtyd can comment better. > There are still too many strings directly used in ImportRole.vue Ignore other language translations except english 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd commented on issue #367: [BUG] apt install fails to cleanup some files after installation due to permissions
rhtyd commented on issue #367: URL: https://github.com/apache/cloudstack-primate/issues/367#issuecomment-635434890 @borisstoyanov can you advise where and how did you test this? I couldn't reproduce it. Instead of direct deb, can you try installation after configuring a repo? The error seems env specific, see similar https://askubuntu.com/questions/908800/what-does-this-synaptic-error-message-mean 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-documentation] onitake opened a new pull request #132: cloud-init and UserData service documentation cleanup
onitake opened a new pull request #132: URL: https://github.com/apache/cloudstack-documentation/pull/132 The cloud-init documentation in the CloudStack manual has always been a bit outdated and was missing a few crucial bits, such as the `data-server.` well-known host name, which is supported by cloud-init This PR is almost a full rewrite to make it clearer and easier to use. One open question: I updated the links to the API docs to 4.14. Is there a generic link that always points to the latest version? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-documentation] onitake commented on pull request #132: cloud-init and UserData service documentation cleanup
onitake commented on pull request #132: URL: https://github.com/apache/cloudstack-documentation/pull/132#issuecomment-635520373 One more thing: Simply base64 the cloud-config and passing it to cloudmonkey is not enough. It needs to be a proper multi-part MIME message, such as this one: ``` Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 --// Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cloud-config.txt" #cloud-config write_files: - path: /testfile content: hello world ``` I think I'm also going to add this to the example. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-documentation] onitake edited a comment on pull request #132: cloud-init and UserData service documentation cleanup
onitake edited a comment on pull request #132: URL: https://github.com/apache/cloudstack-documentation/pull/132#issuecomment-635520373 One more thing: Simply base64-ing the cloud-config and passing it to cloudmonkey is not enough. It needs to be a proper multi-part MIME message, such as this one: ``` Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 --// Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cloud-config.txt" #cloud-config write_files: - path: /testfile content: hello world ``` I think I'm also going to add this to the example. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
