Re: CloudStack Kubernetes provider containers on DockerHub

[Rohit Yadav]

Hi Paul,

I think we added the Dockerfile, I did not actually do anything else. Maybe 
there is a hook that automatically kicks to build and publish container images 
on the apache dockerhub org 
(https://hub.docker.com/r/apache/cloudstack-cloudmonkey). I'm also not part of 
the apache org on dockerhub.

Maybe try adding a Dockerfile if an automatic integration already exists or ask 
asf-dev community?


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Paul Angus 
Sent: Wednesday, January 15, 2020 22:30
To: dev@cloudstack.apache.org ; Rohit Yadav 
; Sven Vogel 
Cc: Pierre-Luc Dion ; Will Stevens ; 
gabrasc...@gmail.com ; Wido den Hollander 
Subject: RE: CloudStack Kubernetes provider containers on DockerHub

Sorry folks, its been hectic...

Yes Pierre-Luc, we should remove the non-Apache accounts.

There is an /apache/cloudstack-cloudmonkey repository so it seems @Rohit Yadav 
knows how to get to upload to there @Sven Vogel

I've been working on and off on docker files for building current simulator, as 
well as rpm/deb packaging images.  I was loosely planning to upload a current 
'empty' simulator and a 'populated' simulator with multiple zones, accounts, 
VMs Networks, Firewall rules etc. It was with new UI development in mind.

I was also thinking of a flow where we'd have automation where if there were 
any updates to the dockerfile we could press a button that would create and 
upload new build images.  An RM would be able to use the 'community' image to 
get a consistent outcome.

Probably Feb before I can make them a polished reality.

@Rohit Yadav can you share the process to get docker images pushed to


Ever the optimist

Paul.



CTO
paul.an...@shapeblue.com
www.shapeblue.com




rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel 
Sent: 14 January 2020 15:47
To: dev 
Cc: Pierre-Luc Dion ; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Pierre, Hi Paul,

@Paul do you know how we proceed. How we can get the space from Apache and 
align to the policy?

Cheers

Sven


__

Sven Vogel
Teamlead Platform

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, Frank Richter
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 13.01.2020 um 15:06 schrieb Pierre-Luc Dion :
>
> Hi Paul,
>
> So we should not use our 2 account but use under apache one instead,
> correct?  if so, I will remove all owner and projects from the 2 I've
> created a while back. they are outdated anyway so better hiding them
> then keep old stuff that can cause confusion.
>
>
> On Sun, Jan 12, 2020 at 4:10 PM Sven Vogel  wrote:
>
>> Hi Paul,
>>
>> I agree! I would do the same If it’s possible.
>>
>> Cheers
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> 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, Frank Richter
>> 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 

[GitHub] [cloudstack-primate] rhtyd merged pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd merged pull request #110: [WIP] - Take Volume Snapshot Action
URL: https://github.com/apache/cloudstack-primate/pull/110
 
 
   


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-primate] RitchieVincent opened a new pull request #113: [WIP] - Dedicated domain

[GitBox]

RitchieVincent opened a new pull request #113: [WIP] - Dedicated domain
URL: https://github.com/apache/cloudstack-primate/pull/113
 
 
   


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-primate] iceteabottle commented on issue #7: [WIP] Feature/vm wizard

[GitBox]

iceteabottle commented on issue #7: [WIP] Feature/vm wizard
URL: https://github.com/apache/cloudstack-primate/pull/7#issuecomment-574765765
 
 
   @rhtyd current status (just a small first part of the network selection):
   
   ![Bildschirmfoto 2020-01-15 um 18 24 
09](https://user-images.githubusercontent.com/13260952/72456141-58bb2980-37c4-11ea-8189-cf2a77ef7fd5.png)
   


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: CloudStack Kubernetes provider containers on DockerHub

[Paul Angus]

Sorry folks, its been hectic...

Yes Pierre-Luc, we should remove the non-Apache accounts.

There is an /apache/cloudstack-cloudmonkey repository so it seems @Rohit Yadav 
knows how to get to upload to there @Sven Vogel

I've been working on and off on docker files for building current simulator, as 
well as rpm/deb packaging images.  I was loosely planning to upload a current 
'empty' simulator and a 'populated' simulator with multiple zones, accounts, 
VMs Networks, Firewall rules etc. It was with new UI development in mind.

I was also thinking of a flow where we'd have automation where if there were 
any updates to the dockerfile we could press a button that would create and 
upload new build images.  An RM would be able to use the 'community' image to 
get a consistent outcome.

Probably Feb before I can make them a polished reality.

@Rohit Yadav can you share the process to get docker images pushed to 


Ever the optimist

Paul.


paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 


-Original Message-
From: Sven Vogel  
Sent: 14 January 2020 15:47
To: dev 
Cc: Pierre-Luc Dion ; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Pierre, Hi Paul,

@Paul do you know how we proceed. How we can get the space from Apache and 
align to the policy?

Cheers

Sven


__

Sven Vogel
Teamlead Platform

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, Frank Richter
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 13.01.2020 um 15:06 schrieb Pierre-Luc Dion :
>
> Hi Paul,
>
> So we should not use our 2 account but use under apache one instead, 
> correct?  if so, I will remove all owner and projects from the 2 I've 
> created a while back. they are outdated anyway so better hiding them 
> then keep old stuff that can cause confusion.
>
>
> On Sun, Jan 12, 2020 at 4:10 PM Sven Vogel  wrote:
>
>> Hi Paul,
>>
>> I agree! I would do the same If it’s possible.
>>
>> Cheers
>>
>>
>> __
>>
>> Sven Vogel
>> Teamlead Platform
>>
>> 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, Frank Richter
>> 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 12.01.2020 um 21:40 schrieb Paul Angus :
>>>
>>> Hey Guys,
>>>
>>> Actually I've been meaning to get round to sorting this. We need to
>> remove 'our' docker hub account and use the Apache run one
>>> https://hub.docker.com/u/apache
>>>
>>> This came up on the Board mailing list with another project. We'll 
>>> need
>> to align ourselves with the policy also.

[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

PaulAngus commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366977136
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+  

[GitHub] [cloudstack-primate] iceteabottle commented on issue #7: [WIP] Feature/vm wizard

[GitBox]

iceteabottle commented on issue #7: [WIP] Feature/vm wizard
URL: https://github.com/apache/cloudstack-primate/pull/7#issuecomment-574729697
 
 
   @rhtyd I'm currently implementing the network selection. That's a complex 
part.
   Did you see my comment here 
(https://github.com/apache/cloudstack-primate/pull/7#discussion_r361663839)?


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] shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366960491
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+   

[GitHub] [cloudstack-documentation] PaulAngus commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

PaulAngus commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366910817
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+  

[GitHub] [cloudstack-primate] RitchieVincent commented on issue #84: [WIP] - Guest network: Many tabs

[GitBox]

RitchieVincent commented on issue #84: [WIP] - Guest network: Many tabs
URL: https://github.com/apache/cloudstack-primate/pull/84#issuecomment-574661029
 
 
   > @RitchieVincent no changes seen here, are you working on them at all? If 
not, please advise.
   
   All fixes should be in place now.


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-primate] RitchieVincent commented on a change in pull request #84: [WIP] - Guest network: Many tabs

[GitBox]

RitchieVincent commented on a change in pull request #84: [WIP] - Guest 
network: Many tabs
URL: https://github.com/apache/cloudstack-primate/pull/84#discussion_r366863447
 
 

 ##
 File path: src/config/section/network.js
 ##
 @@ -47,7 +47,7 @@ export default {
   }, {
 name: 'Egress Rules',
 component: () => import('@/views/network/EgressConfigure.vue'),
-show: record => record.service && record.service.filter(x => x.name 
=== 'Firewall').length > 0
+show: () => true
 
 Review comment:
   @rhtyd This line was the source of the issue with refreshing the page and 
the tab changing away from Egress. It's linked with the fact that there needs 
to be an API call before getting this info, so the tab is always hidden by 
default (whilst waiting for the data) so that when you click the refresh 
button, the tab isn't there, therefore making it unable to maintain that active 
tab state.
   So the potential solution I've implemented is showing the tab at all times, 
and just displaying the default "No Data" message when there are no records 
that match.


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] shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366824849
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
 
 Review comment:
   ```suggestion
   those unmanaged VMs via the importUnmanagedInstance API so that they become 
CloudStack managed guest instances
   ```


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] shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366838572
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+   

[GitHub] [cloudstack-documentation] shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366838347
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+   

[GitHub] [cloudstack-documentation] shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

shwstppr commented on a change in pull request #84: [WIP DO NOT MERGE] VM 
ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#discussion_r366831302
 
 

 ##
 File path: source/adminguide/virtual_machines/VM_Ingestion.rst
 ##
 @@ -0,0 +1,321 @@
+.. 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.
+
+About Importing VMs
+
+
+Unmanaged Virtual Machines
+~~
+
+As of ACS 4.14, CloudStack has the concept of **unmanaged** virtual machines.  
These are virtual machines that are on CloudStack
+managed hosts, but that are not in CloudStack's database and therefore 
CloudStack cannot control (manage) then in any way.  Previously,
+such VMs could exist, but CloudStack did not 'see' them (their existence 
*would* be reported in logs as unrecognised VMs).
+
+From ACS 4.14 onwards, CloudStack is able to list these VMs via the 
listUnmanagedInstances API command and then import (also known as ingest)
+those unamged VMs so that they become CloudStack managed guest instances
+
+.. note:: This is currently only available for **vSphere** clusters.
+
+
+Use Cases and General Usage
+
+
+The ability to import VMs allows Cloud operators (both public and private) on 
onboard new tenants simply and quickly,
+with the minimum amount disk IO. But also can be used in disaster recovery 
scenarios at remote sites (if storage is
+replicated) and in the recreation of VMs which have been backed up (part of 
the code is indeed used in
+CloudStack's Backup and Recovery feature).
+
+The most complex part of importing VMs is the mapping of an unmanaged VM's 
networks to CloudStack networks.  As an operator
+could be importing tens or even hundreds of VMs, a UI for this feature has not 
been created as yet.
+
+If the 'destination' network VLAN(s) and the requested service offerings match 
the existing VM, then the instance can be
+imported whilst it is running. If the VLANs or service offerings do not match, 
then the instance to be imported must be stopped.
+Once the instance has been added to CloudStack, starting it through CloudStack 
will alter the instances settings in line with
+those set in the CloudStack DB.
+
+To import instances, it is imagined that a Cloud Provider will:
+
+#. List all of the existing networks which the instances to be imported are on.
+#. Create corresponding networks in CloudStack
+#. Use the listUnmanagedInstances API to create a CSV of instances to be 
imported.
+#. Where required, add metadata to the CSV such as the Account into which each 
VM is to associated, the network which each VM is to be
+   attached to, the Compute Offering required for each instance, and the Disk 
Offering for each disk
+#. Create a script that will loop through the CSV, sending the 
importUnmanagedInstance API command with the corresponding
+   parameters for each instance being read from the CSV
+
+listUnmanagedInstances API
+--
+
+Prerequisites to list unmanaged instances (vSphere)
+~
+
+In order for CloudStack to list the instances that are not managed by 
CloudStack on a host/cluster, the host(s) in the vSphere cluster
+must have been added to CloudStack.  The standard prerequisites for adding a 
host to CloudStack apply.
+
+API
+~~~
+
+This API will list all unmanaged VMs for a given cluster. Optionally, the 
vSphere name for an existing unmanaged
+VM can be given to retrieve VM details. The API will filter all CloudStack 
managed VMs, and will also filter templates that show up as VMs on vCenter.
+
+**Request parameters**:
+
+.. parsed-literal::
+   - **clusterid** (CloudStack UUID of cluster)
+   - **name** (vSphere instance name)
+
+**Response**:
+
+.. parsed-literal::
+   - **clusterid**
+   - **hostid**
+   - **name**
+   - **osdisplayname**
+   - **memory**
+   - **powerstate**
+   - **cpuCoresPerSocket**
+   - **cpunumber**
+   - **cpuspeed**
+   - **disk**
+  - **id**
+  - **capacity** (in bytes)
+  - **controller**
+  - **controllerunit**
+  - **imagepath**
+  - **position**
+   - **nic**
+  - **id**
+  - **macaddress**
+  - **networkname**
+  - **vlanid**
+   

[GitHub] [cloudstack-primate] RitchieVincent commented on issue #100: [WIP] - Resource view style/layout improvement

[GitBox]

RitchieVincent commented on issue #100: [WIP] - Resource view style/layout 
improvement
URL: 
https://github.com/apache/cloudstack-primate/pull/100#issuecomment-574602296
 
 
   > @RitchieVincent the issues have not been addressed yet:
   > 
   > 1. The width and label issue is not fixed for all a-progress, for example 
in zone/cluster:
   >![Screenshot from 2020-01-15 
12-23-17](https://user-images.githubusercontent.com/95203/72411990-3f00ee80-3792-11ea-84a6-8f2f7f3af2d4.png)
   > 2. The issue of buttons on the bottom of a nic description block in the 
instance hardware tab:
   >![Screenshot from 2020-01-15 
12-25-20](https://user-images.githubusercontent.com/95203/72412009-4d4f0a80-3792-11ea-9eb6-ebae093c1b39.png)
   
   The second issue (buttons) should already be fixed, I applied that fix 
yesterday in #a11f6f9. Could you let me know if you're still seeing the issue, 
and if so, where?
   The progress bar issue is also fixed now, along with a couple of other minor 
tweaks.


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-primate] shwstppr commented on issue #111: [WIP] views: create network action

[GitBox]

shwstppr commented on issue #111: [WIP] views: create network action
URL: 
https://github.com/apache/cloudstack-primate/pull/111#issuecomment-574602034
 
 
   @rhtyd sure, will update you once ready. Later today or tomorrow morning.


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-primate] rhtyd commented on issue #111: [WIP DO NOT MERGE] views: create network action

[GitBox]

rhtyd commented on issue #111: [WIP DO NOT MERGE] views: create network action
URL: 
https://github.com/apache/cloudstack-primate/pull/111#issuecomment-574592314
 
 
   @shwstppr is it complete, ready for review/testing? If not can you ping me 
when it is?


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-primate] DaanHoogland commented on issue #112: [FEATURE] new ldap functionality

[GitBox]

DaanHoogland commented on issue #112: [FEATURE] new ldap functionality
URL: 
https://github.com/apache/cloudstack-primate/issues/112#issuecomment-574591621
 
 
   ok, @rhtyd yet another thing came to mind. there is no ui part for this now, 
but the truststores might need some consideration as well ;)


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-primate] DaanHoogland commented on issue #112: [FEATURE] new ldap functionality

[GitBox]

DaanHoogland commented on issue #112: [FEATURE] new ldap functionality
URL: 
https://github.com/apache/cloudstack-primate/issues/112#issuecomment-574587284
 
 
   this seems to be doubling #39 
   note also that the add ldap configuration and ldap configuration list 
overview are not yet fully functional for this domain level binding:
   
   https://user-images.githubusercontent.com/2486961/72424728-ba5ca300-3786-11ea-8a4b-ce9d8533635f.png;>
   


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-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366790375
 
 

 ##
 File path: src/views/storage/TakeSnapshot.vue
 ##
 @@ -0,0 +1,264 @@
+
+  
+
+  
+{{ $t('label.header.volume.take.snapshot') }}
+  
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+
+{{ $t('tags') }}
+
+  
+
+  {{ tag.key }} = {{ tag.value }}
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  
+
+  
+
+  
+  
+ {{ $t('label.new.tag') }}
+  
+
+
+  
+{{ this.$t('Cancel') }}
+  
+  
+{{ this.$t('OK') }}
+  
+
+  
+
+  
+
+

[GitHub] [cloudstack-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366789526
 
 

 ##
 File path: src/views/AutogenView.vue
 ##
 @@ -32,7 +32,26 @@
 size="small"
 type="dashed"
 icon="reload"
-@click="fetchData()">
+@click="fetchData()" />
+
+
+  
+{{ $t(action.label) }}
+  
+  
 
 Review comment:
   Remove these changes


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-primate] rhtyd commented on issue #112: [FEATURE] new ldap functionality

[GitBox]

rhtyd commented on issue #112: [FEATURE] new ldap functionality
URL: 
https://github.com/apache/cloudstack-primate/issues/112#issuecomment-574589228
 
 
   Thanks @DaanHoogland we've the add ldap config form added (but yes without 
the domainid option)


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-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366789460
 
 

 ##
 File path: src/utils/methods.js
 ##
 @@ -0,0 +1,60 @@
+// 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.
+
+import { api } from '@/api'
+import { message, notification } from 'ant-design-vue'
 
 Review comment:
   @utchoang can you remove this file?


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-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366789575
 
 

 ##
 File path: src/views/storage/TakeSnapshot.vue
 ##
 @@ -0,0 +1,264 @@
+
 
 Review comment:
   Add license


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-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366789657
 
 

 ##
 File path: src/views/storage/TakeSnapshot.vue
 ##
 @@ -0,0 +1,264 @@
+
+  
 
 Review comment:
   Fix typo `take-snapshot`


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-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366789837
 
 

 ##
 File path: src/views/storage/TakeSnapshot.vue
 ##
 @@ -0,0 +1,264 @@
+
+  
+
+  
+{{ $t('label.header.volume.take.snapshot') }}
+  
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+
+{{ $t('tags') }}
+
+  
+
+  {{ tag.key }} = {{ tag.value }}
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  
+
+  
+
+  
+  
+ {{ $t('label.new.tag') }}
+  
+
+
+  
+{{ this.$t('Cancel') }}
+  
+  
+{{ this.$t('OK') }}
+  
+
+  
+
+  
+
+
+
+import { api } from '@/api'
+
+export default {
+  name: 'TakeSnapshot',
+  props: {
+loading: {
+  type: Boolean,
+  default: false
+},
+resource: {
+  type: Object,
+  required: true
+}
+  },
+  data () {
+return {
+  actionLoading: false,
+  quiescevm: false,
+  inputValue: '',
+  inputKey: '',
+  inputVisible: '',
+  tags: [],
+  dataSource: []
+}
+  },
+  beforeCreate () {
+this.form = this.$form.createForm(this)
+this.apiConfig = this.$store.getters.apis.createSnapshot || {}
+this.apiParams = {}
+this.apiConfig.params.forEach(param => {
+  this.apiParams[param.name] = param
+})
+  },
+  mounted () {
+this.quiescevm = this.resource.quiescevm
+  },
+  methods: {
+handleSubmit (e) {
+  e.preventDefault()
+  this.form.validateFields((error, values) => {
+if (error) {
+  return
+}
+
+let params = {}
+params.volumeId = this.resource.id
+if (values.name) {
+  params.name = values.name
+}
+params.asyncBackup = false
+if (values.asyncbackup) {
+  params.asyncBackup = values.asyncbackup
+}
+params.quiescevm = false
+if (values.quiescevm) {
+  params.quiescevm = values.quiescevm
+}
+for (let i = 0; i < this.tags.length; i++) {
+  const formattedTagData = {}
+  const tag = this.tags[i]
+  formattedTagData['tags[' + i + '].key'] = tag.key
+  formattedTagData['tags[' + i + '].value'] = tag.value
+  params = Object.assign({}, params, formattedTagData)
+}
+
+this.actionLoading = true
+const title = this.$t('label.action.take.snapshot')
+const description = this.$t('volume') + ' ' + this.resource.id
+const loading = this.$message.loading(title + 'in progress for ' + 
description, 0)
+api('createSnapshot', params).then(json => {
+  this.checkForAddAsyncJob(json, title, description)
+  this.closeAction()
+}).catch(error => {
+  this.$notification.error({
+message: 'Request Failed',
+description: (error.response && error.response.headers && 
error.response.headers['x-description']) || error.message
+  })
+}).finally(() => {
+  this.actionLoading = false
+  setTimeout(loading, 1000)
+})
+  })
+},
+handleVisibleInterval (intervalType) {
+  if (this.dataSource.length === 0) {
+return false
+  }
+  const dataSource = this.dataSource.filter(item => item.intervaltype === 
intervalType)
+  if (dataSource && dataSource.length > 0) {
+return true
+  }
+  return false
+},
+handleShowButton () {
+  if (this.dataSource.length === 0) {
+return true
+  }
+  const dataSource = this.dataSource.filter(item => item.intervaltype === 
this.intervalValue)
+  if (dataSource && dataSource.length > 0) {
+return false
+  }
+  return true
+},
+handleKeyChange (e) {
+  this.inputKey = e.target.value
+},
+handleValueChange (e) {
+  this.inputValue = e.target.value
+},
+handleInputConfirm () {
+  this.tags.push({
+key: this.inputKey,
+value: this.inputValue
+  })
+  this.inputVisible = false
+  this.inputKey = ''
+  this.inputValue = ''
+},
+checkForAddAsyncJob (json, title, description) {
+  let hasJobId = false
+
+  for (const obj in json) {
+if (obj.includes('response')) {
+  for (const res in json[obj]) {
+if (res === 'jobid') {
+  hasJobId = true
+  const jobId = json[obj][res]
+  this.$store.dispatch('AddAsyncJob', {
+title: 

[GitHub] [cloudstack-primate] rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on a change in pull request #110: [WIP] - Take Volume Snapshot 
Action
URL: https://github.com/apache/cloudstack-primate/pull/110#discussion_r366790200
 
 

 ##
 File path: src/views/storage/TakeSnapshot.vue
 ##
 @@ -0,0 +1,264 @@
+
+  
+
+  
+{{ $t('label.header.volume.take.snapshot') }}
+  
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+
+{{ $t('tags') }}
+
+  
+
+  {{ tag.key }} = {{ tag.value }}
+
+  
+  
+
+  
+  
+  
+  
+
+  
+  
+
+  
+
+  
+  
+ {{ $t('label.new.tag') }}
+  
+
+
+  
+{{ this.$t('Cancel') }}
+  
+  
+{{ this.$t('OK') }}
+  
+
+  
+
+  
+
+

[GitHub] [cloudstack-primate] DaanHoogland opened a new issue #112: [FEATURE] new ldap functionality

[GitBox]

DaanHoogland opened a new issue #112: [FEATURE] new ldap functionality
URL: https://github.com/apache/cloudstack-primate/issues/112
 
 
   changes to the accountWizard since 4.14:
   https://user-images.githubusercontent.com/2486961/72423233-33a6c680-3784-11ea-92f1-de26dea4c67f.png;>
   
   a filter dropdown and a column for the source of a possible conflict
   
   TBD
   
   **Additional context**
   LDAP has different levels of integration. all of which are readonly from a 
cloudstack point of view and which are not distinquished between from the ui at 
the moment.
   Note that the newest, domain level account binding, depends on domain level 
settings.


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] ACSGitBot commented on issue #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

ACSGitBot commented on issue #84: [WIP DO NOT MERGE] VM ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#issuecomment-574569292
 
 
   Build finished.  You can review it at:   
https://acs-www.shapeblue.com/docs/pr84
   
   Build Log Output:
   
   
   No log errors found to report.


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] ACSGitBot commented on issue #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

ACSGitBot commented on issue #84: [WIP DO NOT MERGE] VM ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#issuecomment-574568541
 
 
   Your request had been received, i'll go and build the documentation and 
check the output log for errors.
   
   This shouldn't take long.
   


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 issue #84: [WIP DO NOT MERGE] VM ingestion

[GitBox]

PaulAngus commented on issue #84: [WIP DO NOT MERGE] VM ingestion
URL: 
https://github.com/apache/cloudstack-documentation/pull/84#issuecomment-574568501
 
 
   requesting docbuild


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-primate] utchoang commented on issue #110: [WIP] - Take Volume Snapshot Action

[GitBox]

utchoang commented on issue #110: [WIP] - Take Volume Snapshot Action
URL: 
https://github.com/apache/cloudstack-primate/pull/110#issuecomment-574562408
 
 
   @rhtyd I resolved the conflict PR. Please review again. Thank you


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-primate] shwstppr opened a new pull request #111: [WIP DO NOT MERGE] views: create network action

[GitBox]

shwstppr opened a new pull request #111: [WIP DO NOT MERGE] views: create 
network action
URL: https://github.com/apache/cloudstack-primate/pull/111
 
 
   Adds custom create network action.
   
   ![Screenshot from 2020-01-15 
14-26-53](https://user-images.githubusercontent.com/153340/72419585-20efba00-37a3-11ea-87a6-badaa9670333.png)
   


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: CloudStack Interview Request

[Lalaine L.]

Hi Giles! I hope you are having a wonderful day :) This is just a quick
email to see if you've had a chance to answer the interview questions
(see below) from our previous email? We're just trying to organize our
publishing schedule for this month, so if you could let me know when you
think you could get your responses back to me, that would be great! The
sooner the better :)  

Really looking forward to reading your answers.  

Best. 

Lalaine

> On 2020-01-03 13:30, Lalaine L. wrote: 
> 
> Okay Giles, so I have the interview ready! I really like how it turned out. A 
> few points before you go through it. Interviews tend to do much better in 
> organic search and be more widely shared on social media when they are 
> in-depth and scratch far below the surface, so don't shy away from going 
> deep, being open, getting personal and getting into technical details. Our 
> audience loves long answers, so don't shy away from expanding on your most 
> interesting ideas. There is so much fluff on the web, so we like our 
> interviews to stand out by focusing on exceeding reader expectations. 
> 
> Also, I wanted to get this interview over to you as quickly as possible so it 
> hasn't been edited yet. However, it will be proofread and edited before it 
> goes live on site. 
> 
> You'll find the interview below. When do you think you can have the answers 
> back to me by? 
> 
> p.s. We've been around for some time now, but we're just getting our blog 
> going. You can see a direct link to the blog here: https://erxes.io/blog/ 
> 
> In terms of the audience you'll be speaking to, it's composed of people in 
> the open source space who are interested in learning how to develop, grow and 
> maintain their open source projects.  
> 
> - *** INTERVIEW BELOW *** 
>  
> 
> * First of all, thank you for taking the time to chat with our blog audience 
> today about your experience running Apache CloudStack. Can you kick off the 
> interview by introducing our readers to what Apache CloudStack does, as well 
> as tell us a little more about your history as an open source project? 
> 
> * You've come a long way. Recently you were featured on TechRadar as one of 
> the best laaS platforms in 2020. How have media mentions like this played a 
> role in Apache CloudStack's growth? What has been your approach when it comes 
> to getting media and blog mentions?
> 
> * What have been the top three growth / awareness channels for Apache 
> CloudStack?
> 
> * I notice on your website under the "get involved" page you mention that 
> you're looking for people to help with marketing and awareness. How have 
> these more grassroots marketing initiatives panned out for you? Any major 
> lessons learnt along the way you'd like to share with our readers?
> 
> * From a marketing standpoint, what are the primary differences between 
> promoting an open source project vs a closed source projects? Tell us a bit 
> more about the advantages and disadvantages in terms of marketing an open 
> source project (examples here would be helpful).
> 
> * Tell us a little bit more about your most successful community building 
> initiatives. You're in a highly technical niche which I'm sure narrows your 
> community building possibilities to some degree. However, most open source 
> projects are heavily dependent on the health of their community. In your 
> earliest days how did you go about building up your community and awareness 
> about your project?
> 
> * How have your community building activities changed over time? Where are 
> you putting the majority of your community building efforts today?
> 
> * For you, what's the most exciting thing about being involved in Apache 
> CloudStack?
> 
> * Knowing what you know now, if you had the opportunity to go back in time 
> and talk to a younger version of yourself about what it takes to manage and 
> grow an open source project, what three pieces of advice would you give to 
> your younger self?
> 
> On 2019-12-30 04:26, Giles Sirett wrote: 
> Hi Lalaine
> 
> I'll happily progress this with you
> Could you first please send me a link to your blog and give me an 
> understanding of its audience and purpose
> 
> Kind regards
> Giles
> 
> giles.sir...@shapeblue.com 
> www.shapeblue.com [1]
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
> 
> -Original Message-
> From: Lalaine L.  
> Sent: 27 December 2019 14:56
> To: dev@cloudstack.apache.org
> Subject: CloudStack Interview Request
> 
> Hi there folks at CloudStack! I'm currently reaching out to you today because 
> I'd like to interview you about your experience in the open source software 
> space for our blog. I stumbled onto your site so I thought I'd reach out for 
> an interview :) 
> 
> As far as the interview goes, it would be a text based interview (completed 
> through email) consisting of about ten questions and we would publish it on 
> our blog (see our site in 

[GitHub] [cloudstack-primate] rhtyd commented on issue #7: [WIP] Feature/vm wizard

[GitBox]

rhtyd commented on issue #7: [WIP] Feature/vm wizard
URL: https://github.com/apache/cloudstack-primate/pull/7#issuecomment-574558526
 
 
   Ping @iceteabottle @svenvogel - any update on this?


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-primate] rhtyd commented on issue #110: [WIP] - Take Volume Snapshot Action

[GitBox]

rhtyd commented on issue #110: [WIP] - Take Volume Snapshot Action
URL: 
https://github.com/apache/cloudstack-primate/pull/110#issuecomment-574558065
 
 
   @utchoang the problem of conflict is there again. Can you check/fix it?
   
   Here's what you can do for future PRs:
   - First checkout the latest master and enforce that your version of master 
is same as origin/master, you can do like: git fetch origin/master && git 
checkout master && git reset --hard origin/master
   - Then for every new issue/task, checkout a feature or bugfix branch after 
doing above: git checkout -b 


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-primate] rhtyd merged pull request #99: Recurring Volume Snapshot Custom Action Form

[GitBox]

rhtyd merged pull request #99: Recurring Volume Snapshot Custom Action Form
URL: https://github.com/apache/cloudstack-primate/pull/99
 
 
   


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-primate] rhtyd commented on issue #39: Add LDAP Account Form

[GitBox]

rhtyd commented on issue #39: Add LDAP Account Form
URL: 
https://github.com/apache/cloudstack-primate/issues/39#issuecomment-574545991
 
 
   @utchoang cc @svenvogel - I've added documentation on this task and 
configured LDAP server/config on the acs.shapeblue.com server that you can use 
to build this feature now. Let me know if you've any questions.


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