Re: [Review] CloudStack 4.12.0.0 release announcement review request
Hello Adrian. Some links will be activated soon, and may not be working now. Regards, Gabriel. Em ter, 2 de abr de 2019 às 02:43, escreveu: > Hello Gabriel, > > Would you be able to check permissions on the release notes: > Permission Denied > You don't have the proper permissions to view this page. Please contact > the owner of this project to request permission. > > Regards, > Adrian Sender > > > On 2019-04-02 02:59, Gabriel Beims Bräscher wrote: > > All, > > > > Kindly review: (some links will be activated soon, and may not be > > working > > now) > > > > ### START ### > > > > # Apache CloudStack non-LTS Release 4.12.0.0 > > > > The Apache CloudStack project is pleased to announce the release of the > > CloudStack 4.12.0.0. The CloudStack version 4.12.0.0 is a 4.12 non-LTS > > release, adding multiple features for those who want to access a fresh > > CloudStack prior to the next LTS. The release 4.12.0.0 combines 12 > > months > > of work and adds +200 commits, with multiple new features and fixes. > > > > Apache CloudStack is an integrated Infrastructure-as-a-Service (IaaS) > > software platform that allows users to build feature-rich public and > > private cloud environments. CloudStack includes an intuitive user > > interface > > and rich API for managing the compute, networking, software, and > > storage > > resources. The project became an Apache top level project in March, > > 2013. > > > > More information about Apache CloudStack can be found at: > > http://cloudstack.apache.org/ > > > > # Documentation > > > > What's new in CloudStack 4.12.0.0 > > > http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.12.0.0/about.html > > > > The 4.12.0.0 release notes include a full list of corrected issues, as > > well > > as upgrade instructions from previous versions of Apache CloudStack, > > and > > can be found at: > > > http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.12.0.0 > > > > The official installation, administration and API documentation for > > each > > release are available on our Documentation Page: > > http://docs.cloudstack.apache.org/ > > > > # Downloads > > > > The official source code for the 4.12.0.0 release can be downloaded > > from > > our downloads page: > > http://cloudstack.apache.org/downloads.html > > > > The official source code release can be downloaded from: > > 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://cloudstack.apt-get.eu/ubuntu/dists/ > > http://cloudstack.apt-get.eu/centos/6/ > > http://cloudstack.apt-get.eu/centos/7/ > > > > ### END ### > > > > Regards, > > Gabriel Bräscher >
Re: [DISCUSS] WIP PRs and contribution transparency
> In order to be more transparent, I would like to propose that we put > something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues > and I have done on some new PRs you can follow. Labels cannot be used > as not every contributor is a committer. Once the PR is ready for > merging, we can remove it. Is it possible to attach bots to PRs, like for Issues? That way, a bot could take care of attaching and removing labels, and access control could be done according to the contributor's role.
Re: [DISCUSS] WIP PRs and contribution transparency
Hi Gregor, currently we don't have access to any bot service as those accesses are restricted to only committers of the repositories now. Maybe one of us can explore the possibility of using our GitHub account to do it, but that's a good to have feature. Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com From: Riepl, Gregor (SWISS TXT) Sent: Tuesday, April 2, 2019 6:33:06 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] WIP PRs and contribution transparency > In order to be more transparent, I would like to propose that we put > something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues > and I have done on some new PRs you can follow. Labels cannot be used > as not every contributor is a committer. Once the PR is ready for > merging, we can remove it. Is it possible to attach bots to PRs, like for Issues? That way, a bot could take care of attaching and removing labels, and access control could be done according to the contributor's role. rohit.ya...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection
PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection URL: https://github.com/apache/cloudstack-documentation/pull/28#discussion_r271365087 ## File path: source/plugins/ovs-plugin.rst ## @@ -364,6 +364,47 @@ To enable DPDK on VM deployments: dpdk-interface-model: +Additional configurations on service offerings Review comment: A title of something like: Applying 'Additional Configurations' via Service Offerings might be clearer, I misunderstood it the first time that I read it 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 With regards, Apache Git Services
[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection
PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection URL: https://github.com/apache/cloudstack-documentation/pull/28#discussion_r271368976 ## File path: source/plugins/ovs-plugin.rst ## @@ -364,6 +364,47 @@ To enable DPDK on VM deployments: dpdk-interface-model: +Additional configurations on service offerings +~~ + +It is also possible to avoid passing additional configuration on each VM deployment, but setting these configurations on a service offering, and those are passed to the VM. To create a service offering with additional configurations, pass each key/value pair as service offering details on service offering creation, with keys starting with the "extraconfig" keyword, and each value an URL UTF-8 encoded string. For example: + +:: + + create serviceoffering name= displaytext= serviceofferingdetails[0].key=extraconfig-dpdk-hugepages serviceofferingdetails[0].value=%3CmemoryBacking%3E%20%3Chugepages%2F%3E%20%3C%2FmemoryBacking%3E serviceofferingdetails[1].key=extraconfig-dpdk-numa serviceofferingdetails[1].value=%3Ccpu%20mode%3D%22host-passthrough%22%3E%20%3Cnuma%3E%20%3Ccell%20id%3D%220%22%20cpus%3D%220%22%20memory%3D%229437184%22%20unit%3D%22KiB%22%20memAccess%3D%22shared%22%2F%3E%20%3C%2Fnuma%3E%20%3C%2Fcpu%3E + +Additional configurations are stored as service offering details. + +DPDK vHost User mode selection +~~ +The vHost user mode describes a client/server model between Openvswitch along with DPDK and QEMU, in which one acts as client while the other as server. The server creates and manages the vHost user sockets and the client connects to the sockets created by the server: + +- DPDK vHost user server mode: + - Is the default configuration. + - OVS with DPDK acts as the server, while QEMU acts as the client. + - The port types used are: dpdkvhostuser + +- DPDK vHost user client mode: + - OVS with DPDK acts as the client and QEMU acts as the server. + - If Openvswitch is restarted then the sockets can reconnect to the existing sockets on the server, and normal connectivity can be resumed. + - The port types used are: dpdkvhostuserclient + +It is possible to pass the DPDK vHost User mode as a service offering detail with key: "DPDK-VHOSTUSER" and values: "client" or "server". The following table illustrates the expected behaviour on DPDK ports and VM guest interfaces. Review comment: Can this only be passed via a service offering ? Maybe the Mode options should be explained before the ability to embed dpdk in the service offerings. And then the ability to use service offerings explained separately 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 With regards, Apache Git Services
Re: Proposal for EFI firmware support on KVM
Thanks! -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Sven Vogel" > To: "dev" > Sent: Wednesday, 27 March, 2019 22:34:24 > Subject: Re: Proposal for EFI firmware support on KVM > Hi Nux, > > I think kvm is the same like VMware. Have a look here. > > „Do I need a host with EFI firmware? > > No. The host's firmware is totally independent of the virtual machine's > firmware, so BIOS hosts can run EFI virtual machines, and EFI hosts can run > BIOS virtual machines. „ > > https://communities.vmware.com/docs/DOC-28494 > > Von > >> Am 27.03.2019 um 13:06 schrieb Nux! : >> >> Stupid question: does the hypervisor need to be running in EFI mode as well >> for >> this to work properly? >> >> I don't think that's a requirement at all, but just making sure. I am >> avoiding >> EFI like the plague, but at some point I'll need to bite the bullet. >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> - Original Message - >>> From: "Nathan Johnson" >>> To: "dev" >>> Sent: Wednesday, 13 March, 2019 14:29:29 >>> Subject: Proposal for EFI firmware support on KVM >> >>> I've put together an approach for EFI support that we would like to get some >>> feedback on before I create a PR. Constructive criticism would be >>> appreciated. >>> >>> I've added the following properties to be configured in the >>> agent.properties: >>> >>> guest.loader.efi - boolean to switch efi on. This must be true before it >>> will >>> inject any entries into the domain xml >>> guest.loader.image - this would be the path to the bios/efi image >>> guest.loader.nvram - this optionally points to an nvram image >>> >>> >>> Even when a host is configured so that it can use EFI, it will only actually >>> create a virtual machine when both of the following conditions are met: >>> >>> 1) the host has guest.locader.efi set to true in its agent.properties >>> 2) the vm has the vm details parameter efi=true >>> >>> At present there is no automatic way for the management server to know in >>> advance which hosts have EFI enabled. I suppose this could be approximated >>> using tags. It might be nice to make this more automatic, and have the >>> resource planner aware of the efi toggle on the VM, but I'm not sure how >>> best >>> to implement that or if it's even worth it. >>> >>> Thanks in advance! >>> >>> >>> Nathan Johnson >>> Senior R&D Engineer > >> Education Networks of America
[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection
PaulAngus commented on a change in pull request #28: DPDK vHost User mode selection URL: https://github.com/apache/cloudstack-documentation/pull/28#discussion_r271401151 ## File path: source/plugins/ovs-plugin.rst ## @@ -377,7 +418,7 @@ That would set interfaces to type 'vhostuser' and reference the ports created in :: - + Review comment: It might be helpful to give a specific example wrt I don't know if 'people' would know what was expected here, I believe it is the path to the OVS database. 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 With regards, Apache Git Services
IPv6 in SG zones
Hello, I'm looking to deploy a new Adv+SG zone and want to go the extra mile and have IPv6 as well for VMs, however according to what docs I could find IPv6 support is still not complete (missing firewall/security groups for one), whereas I thought it was not the case. Can someone clarify for me if security groups are available for IPv6 addresses and maybe point me into a good direction with regards to RTFM? Regards, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: IPv6 in SG zones
https://github.com/apache/cloudstack/pull/3053 https://github.com/apache/cloudstack/pull/3070 ^^^ comes to my mind, in 4.12 only... On Tue, 2 Apr 2019 at 22:01, Nux! wrote: > Hello, > > I'm looking to deploy a new Adv+SG zone and want to go the extra mile and > have IPv6 as well for VMs, however according to what docs I could find IPv6 > support is still not complete (missing firewall/security groups for one), > whereas I thought it was not the case. > Can someone clarify for me if security groups are available for IPv6 > addresses and maybe point me into a good direction with regards to RTFM? > > Regards, > Lucian > > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > -- Andrija Panić
