Re: CWiki access / new page request

[Daan Hoogland]

assuming you are nlivens in cwiki you are added.

On Tue, Feb 23, 2016 at 8:29 AM, Nick LIVENS 
wrote:

> Hi,
>
> I want to submit a design document for CloudStack. I don't have any write
> access to the CWiki. I've created a ticket on INFRA, but they redirect me
> here.
> Could anyone give me edit permissions to the following page :
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
>
> Or if that's not possible, could you create a subpage "4.9 Design
> Documents" with an additional subpage called " VPC Inline LB Plugin (VPC
> Public Load Balancing)" and give me edit rights to that page only?
>
> Thanks!
>



-- 
Daan

CWiki access / new page request

[Nick LIVENS]

Hi,

I want to submit a design document for CloudStack. I don't have any write
access to the CWiki. I've created a ticket on INFRA, but they redirect me
here.
Could anyone give me edit permissions to the following page :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design

Or if that's not possible, could you create a subpage "4.9 Design
Documents" with an additional subpage called " VPC Inline LB Plugin (VPC
Public Load Balancing)" and give me edit rights to that page only?

Thanks!

[GitHub] cloudstack pull request: CLOUDSTACK-8886: Limitations is listUsage...

[kansal]

Github user kansal commented on the pull request:

https://github.com/apache/cloudstack/pull/858#issuecomment-187574951
  
Can someone else review this as well? Already have unit test cases in the 
PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-9261: Query to traffic sentine...

[kansal]

Github user kansal commented on the pull request:

https://github.com/apache/cloudstack/pull/1418#issuecomment-187574586
  
@alexandrelimassantana , I am not sure of how to simulate the actual 
traffic sentinel resource. I can create a request with 20148 or more, but the 
actual error is encountered when the request reaches the resource. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Strongswan vpn feature

[jayapalu]

Github user jayapalu commented on the pull request:

https://github.com/apache/cloudstack/pull/872#issuecomment-187544886
  
@pdion891 I did not see the issue you are facing.
I have enabled the remote access vpn from the cloudstack UI. I can see 
xl2tpd running. I can also restart the xl2tpd on VR.
It seems your sysemvm.iso is not latest. There is comment in the first line 
for latest file.
~# cat /etc/ipsec.d/l2tp.conf 
#ipsec remote access vpn configuration
conn L2TP-PSK
authby=psk


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: CS slack channel

[Rafael Weingärtner]

Sure, you are now officially invited

On Mon, Feb 22, 2016 at 6:51 PM, Nicolás Vázquez 
wrote:

> Hi,
>
> Can I have an invitation to the Slack channel?
>
> Thanks,
> Nicolas
>
> 2015-12-03 11:48 GMT-03:00 Nux! :
>
> > https://drewdevault.com/2015/11/01/Please-stop-using-slack.html
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> > > From: "Nguyen Anh Tu" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Thursday, 3 December, 2015 14:35:24
> > > Subject: Re: CS slack channel
> >
> > > Great to hear CS is now happening in Slack. Could you send me an
> > invitation
> > > as well, Daan ?
> > >
> > >
> > > On Thu, Dec 3, 2015 at 9:08 PM, Simon Weller  wrote:
> > >
> > >> Daan,
> > >>
> > >>
> > >> Could you send me an invite to the CloudStack Slack Team please?
> > >>
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> - Si
> >
>



-- 
Rafael Weingärtner

Re: CS slack channel

[Nicolás Vázquez]

Hi,

Can I have an invitation to the Slack channel?

Thanks,
Nicolas

2015-12-03 11:48 GMT-03:00 Nux! :

> https://drewdevault.com/2015/11/01/Please-stop-using-slack.html
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Nguyen Anh Tu" 
> > To: dev@cloudstack.apache.org
> > Sent: Thursday, 3 December, 2015 14:35:24
> > Subject: Re: CS slack channel
>
> > Great to hear CS is now happening in Slack. Could you send me an
> invitation
> > as well, Daan ?
> >
> >
> > On Thu, Dec 3, 2015 at 9:08 PM, Simon Weller  wrote:
> >
> >> Daan,
> >>
> >>
> >> Could you send me an invite to the CloudStack Slack Team please?
> >>
> >>
> >> Thanks,
> >>
> >>
> >> - Si
>

[GitHub] cloudstack pull request: CLOUDSTACK-9252: Support configurable NFS...

[nvazquez]

Github user nvazquez commented on the pull request:

https://github.com/apache/cloudstack/pull/1361#issuecomment-187396165
  
Hi @rafaelweingartner @kishankavala I've run test_ssvm.py, 
test_secondary_storage.py and test_vm_life_cycle.py 
integration tests under real hardware. This are my results:

```
[root@ussarlabcsmgt41 cloudstack]# cat 
/tmp/MarvinLogs/test_vm_life_cycle_SFRI8J/results.txt
Test system VM start ... === TestName: test_01_sys_vm_start | Status : 
SUCCESS ===
ok
Test system templates are ready ... === TestName: 
test_02_sys_template_ready | Status : SUCCESS ===
ok
Test List secondary storage VMs ... === TestName: 
test_01_list_sec_storage_vm | Status : SUCCESS ===
ok
Test List console proxy VMs ... === TestName: test_02_list_cpvm_vm | Status 
: SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test advanced zone virtual router ... === TestName: 
test_advZoneVirtualRouter | Status : SUCCESS ===
ok
Tests for basic zone virtual router ... === TestName: 
test_basicZoneVirtualRouter | Status : SUCCESS ===
ok
Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status : 
SUCCESS ===
ok
Test Multiple Deploy Virtual Machine ... === TestName: 
test_deploy_vm_multiple | Status : SUCCESS ===
ok
Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status : 
SUCCESS ===
ok
Test Start Virtual Machine ... === TestName: test_02_start_vm | Status : 
SUCCESS ===
ok
Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status : 
SUCCESS ===
ok
Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status 
: SUCCESS ===
ok
Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status 
: SUCCESS ===
ok
Test migrate VM ... === TestName: test_08_migrate_vm | Status : SUCCESS ===
ok
Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm 
| Status : SUCCESS ===
ok
Test for attach and detach ISO to virtual machine ... === TestName: 
test_10_attachAndDetach_iso | Status : SUCCESS ===
ok

--
Ran 24 tests in 2128.458s

OK
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Improve ordering of fields of VPC router ...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1422#issuecomment-187386982
  
@remibergsma sounds like you got the tone of comment just right.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Improve ordering of fields of VPC router ...

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1422#issuecomment-187368247
  
@DaanHoogland I debugged so many routers recently that I think it's fair to 
say this info on the top is most valuable :-) But feel free to disagree.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-9175: [VMware DRS] Adding new ...

[resmo]

Github user resmo commented on the pull request:

https://github.com/apache/cloudstack/pull/1248#issuecomment-187360919
  
@sureshanaparti yes, that would be great


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Keeping system vms up to date

[Rene Moser]

Erik

On 02/22/2016 01:50 PM, Erik Weber wrote:
> Adding a boilerplate in the install/admin docs that says "If you have no
> other tools in place to handle system vm updates, consider enabling this
> option: x.y.z" is good enough for me.
> This is supposed to be a way for all those who don't have any other/better
> means of doing this, not a mandatory/forced way of doing it for everyone
> else.

Sounds good. :)


>> I would like to see an api for download and update latest system-vm
>> template. AFAIK this is still not solved (without touching DB) to update
>> system-vm templates having same version.

What do you think about security updating system VM templates?
Up-to-date system vm templates would be needed anyway.

>> This way it would be up to the user to handle the upgrade and to think a
>> bit further we could also define a rollback scenario (use previous
>> template).
>>
>>
> This thread is ment to discuss varies ways to achieve the goal, I did not
> mean to propose a single way of doing it.
> Pushing an ansible inventory script (that works with all major ACS
> hypervisors) and a playbook is another option.

It is a shame but I have no experience with "other hypervisors" with
ACS, just VMware. :( How are KVM/XEN different in VRs then VMware, isn't
there a VR accessible by SSH (by so called "linklocal" IP) from ACS
management node?

René

[GitHub] cloudstack pull request: CLOUDSTACK-9142 Migrate VM changes xmlDes...

[davidamorimfaria]

Github user davidamorimfaria commented on the pull request:

https://github.com/apache/cloudstack/pull/1348#issuecomment-187342982
  
LGTM, 4.7.1 with this fix was installed on a live environment with success. 
Instances can now be migrated to and from the kvm node that has an IP address 
which partially matches one of the ceph monitor nodes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: systemvm: preserve file permissions, set ...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1420#issuecomment-187282499
  
@DaanHoogland I don't have access on Apache jenkins; also this would 
require some S3 storage or large disk space if we want to keep the rpms (say at 
least for a month or two)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: systemvm: preserve file permissions, set ...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1420#issuecomment-187261697
  
@bhaisaab can you port that job to apache?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Improve ordering of fields of VPC router ...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1422#issuecomment-187260678
  
I agree with this at first sight. so LGTM but is this debatable? that would 
inspire a requirement to have it conigurable or so, no? maybe this is not the 
place for that discussion but that doesn't keep me from starting it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [PROPOSAL] - Reference Guide for CloudStack configuration parameters

[Pierre-Luc Dion]

Good Initiative Rajsekhar !

I think this document should go into the admin-guide [1]. For sure the wiki
is easier to start with :-)

Thanks !

PL


On Tue, Feb 16, 2016 at 4:49 AM, Rajsekhar K 
wrote:

> Hi, All,
>
> Thanks for your responses. I am sure we will be able to create a complete
> reference guide for the CloudStack parameters.
>
> I think I can create a wiki page that explains this effort and publish this
> list of categories there. I think it will be easier for you to review the
> list then.
>
> Will let you know after I create this wiki page.
>
> Thanks,
> Rajsekhar
>
> On Mon, Feb 15, 2016 at 5:07 PM, Daan Hoogland 
> wrote:
>
> > I like the idea but shouldn't it be part of the source code and extracted
> > from there? What is the need to have it in a separate wiki?
> >
> > On Mon, Feb 15, 2016 at 9:18 AM, Rohit Yadav 
> > wrote:
> >
> > > Nice, maybe put this on our cwiki so others can collaborate than do
> this
> > > over a word doc?
> > >
> > > Regards.
> > >
> > >
> > > [image: ShapeBlue] 
> > > Rohit Yadav
> > > Software Architect ,  ShapeBlue
> > > d:  * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540>  |
> m:
> > > *+91 8826230892* <+91%208826230892>
> > > e:  *rohit.ya...@shapeblue.com | t: *
> > >   |  w:  *www.shapeblue.com*
> > > 
> > > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> > > Services India LLP is a company incorporated in India and is operated
> > under
> > > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> > > company incorporated in Brasil and is operated under license from Shape
> > > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic
> of
> > > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> > is
> > > a registered trademark.
> > > This email and any attachments to it may be confidential and are
> intended
> > > solely for the use of the individual to whom it is addressed. Any views
> > or
> > > opinions expressed are solely those of the author and do not
> necessarily
> > > represent those of Shape Blue Ltd or related companies. If you are not
> > the
> > > intended recipient of this email, you must neither take any action
> based
> > > upon its contents, nor copy or show it to anyone. Please contact the
> > sender
> > > if you believe you have received this email in error.
> > >
> > >
> > > On 14-Feb-2016, at 5:37 AM, Rajsekhar K 
> > wrote:
> > >
> > > Hi, All,
> > >
> > > This is part of the effort to create a Reference Guide for CloudStack
> > > configuration parameters. This guide intends to provide a single point
> of
> > > reference for the configuration parameters that we use in CloudStack.
> > Each
> > > parameter will be treated as a topic in this guide.
> > >
> > > I am planning to document the following information for each parameter:
> > >
> > >
> > >- Name and description of the parameter.
> > >- List of features that the users can configure using the parameter.
> > >- Changes in the behavior of each parameter when users provide low,
> > >optimal, and high values to the parameters.
> > >- Warnings, notes, and limitations for each parameter.
> > >- Example for each parameter - Explaining the parameter with the
> help
> > >of scenarios.
> > >- Impact of each configuration parameter on APIs.
> > >- Scope of the parameter - global, zone-level, or cluster-level.
> > >- Dependencies among the configuration parameters.
> > >- Category to which the parameter belongs.
> > >
> > >
> > > Will let you know more about this effort as we progress with this
> guide.
> > >
> > > Please find attached the list of CloudStack parameters that are
> > > categorized according to the functional areas they belong to. Could you
> > > please review this list and let me know your review
> comment/confirmation?
> > >
> > > Also, I have a few parameters listed under the heading * Others (To be
> > > categorized)*. Could you please help me categorize these parameters?
> > >
> > > Thanks,
> > > Rajsekhar
> > > 
> > >
> > >
> > > Regards.
> > >
> > > Find out more about ShapeBlue and our range of CloudStack related
> > services:
> > > IaaS Cloud Design & Build
> > >  | CSForge – rapid
> > > IaaS deployment framework 
> > > CloudStack Consulting  |
> > CloudStack
> > > Software Engineering
> > > 
> > > CloudStack Infrastructure Support
> > >  | CloudStack
> > > Bootcamp Training Courses 
> > >
> >
> >
> >
> 

[GitHub] cloudstack pull request: systemvm: preserve file permissions, set ...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1420#issuecomment-187236270
  
PR Jenkins RPM build-regression job: 
http://jenkins.bhaisaab.org:/job/cloudstack/160/


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Bug: EGRESS left on ACCEPT in certain circumstances

[Nux!]

https://issues.apache.org/jira/browse/CLOUDSTACK-9295


On isolated networks, when allowing 0.0.0.0/0 on EGRESS for "ALL" and then 
removing that, the rules are not properly cleaned, leaving the chain actually 
accepting all traffic!

Please see http://img.nux.ro/fP3-Selection_123.png


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

[GitHub] cloudstack pull request: Restore iptables at once using iptables-r...

[borisroman]

Github user borisroman closed the pull request at:

https://github.com/apache/cloudstack/pull/1400


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Map LDAP group to Cloudstack account

[miguelaferreira]

Github user miguelaferreira closed the pull request at:

https://github.com/apache/cloudstack/pull/1285


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-9142 Migrate VM changes xmlDes...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1348#issuecomment-187167486
  
@remibergsma @wido can we merge this?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 1:18 PM, Rene Moser  wrote:

> Hi
>
> I don't like the idea cloudstack management handles the "apt-get update
> && apt-get upgrade" (I am -1 for this solution) or at least I would like
> to disable it by configuration, if we go this direction.
>

It should by no means be mandatory, and wether or not it should be default
on is up for debate.
I have no strong opinion about the latter.

Adding a boilerplate in the install/admin docs that says "If you have no
other tools in place to handle system vm updates, consider enabling this
option: x.y.z" is good enough for me.

This is supposed to be a way for all those who don't have any other/better
means of doing this, not a mandatory/forced way of doing it for everyone
else.


We use ansible (what a surprise) to update the VR and also add some
> custom patches to it. We have a dynamic inventory getting all the VR
> with linklocal IP as ssh host and regulary run playbooks to these VRs
> running by a jenkins job.
>
> This sounds a bit kind of a hack at the beginning but it has the
> advantage that we are able to run the very same playbooks also against
> our test and stage cloud. Which gives a good feeling.
>
> I would like to see an api for download and update latest system-vm
> template. AFAIK this is still not solved (without touching DB) to update
> system-vm templates having same version.
>
> This way it would be up to the user to handle the upgrade and to think a
> bit further we could also define a rollback scenario (use previous
> template).
>
>
This thread is ment to discuss varies ways to achieve the goal, I did not
mean to propose a single way of doing it.
Pushing an ansible inventory script (that works with all major ACS
hypervisors) and a playbook is another option.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

We are comparing different sources, I was comparing the 'official' e.g. the
documented template, not the one regularely built by jenkins.

-- 
Erik


On Mon, Feb 22, 2016 at 1:11 PM, Remi Bergsma 
wrote:

> It _must_ be lying :-)
>
> When I install a systemvm from this last build:
>
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-xen.vhd.bz2
>
>
> It has 4.6.0 version, but /etc/cloudstack-version shows it was built today.
>
> cat /etc/cloudstack-release
> Cloudstack Release 4.6.0 Mon Feb 22 09:33:04 UTC 2016
>
> Regards,
>
> Remi
>
>
>
>
>
>
> On 22/02/16 12:23, "Erik Weber"  wrote:
>
> >On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma <
> rberg...@schubergphilis.com>
> >wrote:
> >
> >> Hi Erik,
> >>
> >> The version might not change, but Jenkins builds new ones every night
> with
> >> latest OS patches:
> >> http://jenkins.buildacloud.org/job/build-systemvm64-master/
> >>
> >> Option 1) and 3) will work once we allow more space on the systemvm
> >> template for it to actually handle installing stuff. You then also
> assume
> >> they have internet acces, which may not be true.
> >>
> >>
> >If they aren't accessible from the internet then securing them isn't as
> >important either.
> >You still have to factor in the internal risk, but that is generally far
> >lower than the external risk.
> >
> >In cases where it is accessible from the internet, but does not have
> >outgoing access to the internet you're up for a treat.
> >
> >
> >
> >> Option 2) I think we already do that?
> >>
> >>
> >
> >Unless the web server is lying to me, then no:
> >eriweb@eriweb:~$ curl -Is
> >
> http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
> >| grep Last-Modified
> >Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT
> >
> >
> >You can always upload a new template and replace it (a global config like
> >> systemvm.minversion or so exists). This will require to reboot all
> routers
> >> currently.
> >>
> >>
> >Sure I know that, but to replace the whole system vm just to update glibc,
> >haproxy or what have you seems a bit extreme.
> >
> >My intention for this thread was to figure out if we can provide
> cloudstack
> >users a way to ensure their system vms are kept up to date.
> >It should be optional so that more advanced users or those without
> internet
> >etc. don't run into issues because of it, while still keeping all those
> >small clouds that 'just works' safe and secure.
> >
> >--
> >Erik
>

RE: [DISCUSS] Keeping system vms up to date

[Paul Angus]

I think that there are two parts to this - creating system VMs and installing 
them.

The systemvms need to have the automated build with versioning 4.5.2-1234 (I'd 
like to see that shown in log on screen of all system vms)

+ we should have some direct control available in CloudStack of which template 
is the system VM template. And be able to upload a template as 'SYSTEM'.


[ShapeBlue]
Paul Angus
VP Technology   ,   ShapeBlue


d:  +44 203 617 0528 | s: +44 203 603 
0540 |  
m:  +44 7711 418784

e:  paul.an...@shapeblue.com | t: 
@cloudyangus  |
  w:  www.shapeblue.com

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagef433a4.png@a42641b9.4cba1c4d]


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services 
India LLP is a company incorporated in India and is operated under license from 
Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in 
Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd 
is a company registered by The Republic of South Africa and is traded under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error.




-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Monday, February 22, 2016 9:37 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Keeping system vms up to date

Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the 
cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of 
ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as 
Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Erik Weber" 
> To: "dev" 
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> As of 4.6 or so, we don't really need to distribute new system vm
> templates all that often, and that is great for upgrades, but less so
> from a security perspective.
>
> With the current approach we ship old system vm templates, with out of
> date packages, and there is currently no good out of the box way to handle 
> that.
>
> There is a few ways to handle it, including, but not limited to:
>
> 1) Introduce a configuration value that specifies if you want to run
> apt-get update && apt-get upgrade on boot. This slows down deployments
> and will only get worse as times passes and there are more packages to update.
> An alternative is to specify a list of packages we _HAVE_ to keep
> updated and only update those.
>
> 2) Package new system vms for all releases, but not bump the version
> number (or introduce a patch version number). This is ment to ensure
> that new cloud deployments are somewhat up to date, but won't update
> existing ones nor ensure that the deployment is kept up to date.
>
> 3) Add an optional? cronjob that does apt-get update && apt-get
> upgrade, the downside is that you risk having some downtime for certain 
> services.
>
> 4) A combination of the previous 3.
>
> And most likely other options I haven't thought of.
>
> I feel we need to address this somehow or else we risk ending up as a
> very negative headliner when the right (or wrong) bug/exploit gets out
> and takes down a bunch of clouds..
>
> --
> Erik
Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build | 
CSForge – rapid IaaS deployment framework
CloudStack Consulting | 
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support | CloudStack 
Bootcamp Training Courses

Re: [DISCUSS] Keeping system vms up to date

[Rene Moser]

Hi

I don't like the idea cloudstack management handles the "apt-get update
&& apt-get upgrade" (I am -1 for this solution) or at least I would like
to disable it by configuration, if we go this direction.

We use ansible (what a surprise) to update the VR and also add some
custom patches to it. We have a dynamic inventory getting all the VR
with linklocal IP as ssh host and regulary run playbooks to these VRs
running by a jenkins job.

This sounds a bit kind of a hack at the beginning but it has the
advantage that we are able to run the very same playbooks also against
our test and stage cloud. Which gives a good feeling.

I would like to see an api for download and update latest system-vm
template. AFAIK this is still not solved (without touching DB) to update
system-vm templates having same version.

This way it would be up to the user to handle the upgrade and to think a
bit further we could also define a rollback scenario (use previous
template).

Regards
René



On 02/22/2016 09:53 AM, Erik Weber wrote:
> As of 4.6 or so, we don't really need to distribute new system vm templates
> all that often, and that is great for upgrades, but less so from a security
> perspective.
> 
> With the current approach we ship old system vm templates, with out of date
> packages, and there is currently no good out of the box way to handle that.
> 
> There is a few ways to handle it, including, but not limited to:
> 
> 1) Introduce a configuration value that specifies if you want to run
> apt-get update && apt-get upgrade on boot. This slows down deployments and
> will only get worse as times passes and there are more packages to update.
> An alternative is to specify a list of packages we _HAVE_ to keep updated
> and only update those.
> 
> 2) Package new system vms for all releases, but not bump the version number
> (or introduce a patch version number). This is ment to ensure that new
> cloud deployments are somewhat up to date, but won't update existing ones
> nor ensure that the deployment is kept up to date.
> 
> 3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
> the downside is that you risk having some downtime for certain services.

Re: [DISCUSS] Keeping system vms up to date

[Remi Bergsma]

It _must_ be lying :-)

When I install a systemvm from this last build:
http://jenkins.buildacloud.org/job/build-systemvm64-master/lastBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-xen.vhd.bz2


It has 4.6.0 version, but /etc/cloudstack-version shows it was built today.

cat /etc/cloudstack-release
Cloudstack Release 4.6.0 Mon Feb 22 09:33:04 UTC 2016

Regards,

Remi






On 22/02/16 12:23, "Erik Weber"  wrote:

>On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma 
>wrote:
>
>> Hi Erik,
>>
>> The version might not change, but Jenkins builds new ones every night with
>> latest OS patches:
>> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>>
>> Option 1) and 3) will work once we allow more space on the systemvm
>> template for it to actually handle installing stuff. You then also assume
>> they have internet acces, which may not be true.
>>
>>
>If they aren't accessible from the internet then securing them isn't as
>important either.
>You still have to factor in the internal risk, but that is generally far
>lower than the external risk.
>
>In cases where it is accessible from the internet, but does not have
>outgoing access to the internet you're up for a treat.
>
>
>
>> Option 2) I think we already do that?
>>
>>
>
>Unless the web server is lying to me, then no:
>eriweb@eriweb:~$ curl -Is
>http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
>| grep Last-Modified
>Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT
>
>
>You can always upload a new template and replace it (a global config like
>> systemvm.minversion or so exists). This will require to reboot all routers
>> currently.
>>
>>
>Sure I know that, but to replace the whole system vm just to update glibc,
>haproxy or what have you seems a bit extreme.
>
>My intention for this thread was to figure out if we can provide cloudstack
>users a way to ensure their system vms are kept up to date.
>It should be optional so that more advanced users or those without internet
>etc. don't run into issues because of it, while still keeping all those
>small clouds that 'just works' safe and secure.
>
>-- 
>Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma 
wrote:

> Hi Erik,
>
> The version might not change, but Jenkins builds new ones every night with
> latest OS patches:
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> Option 1) and 3) will work once we allow more space on the systemvm
> template for it to actually handle installing stuff. You then also assume
> they have internet acces, which may not be true.
>
>
If they aren't accessible from the internet then securing them isn't as
important either.
You still have to factor in the internal risk, but that is generally far
lower than the external risk.

In cases where it is accessible from the internet, but does not have
outgoing access to the internet you're up for a treat.



> Option 2) I think we already do that?
>
>

Unless the web server is lying to me, then no:
eriweb@eriweb:~$ curl -Is
http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
| grep Last-Modified
Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT


You can always upload a new template and replace it (a global config like
> systemvm.minversion or so exists). This will require to reboot all routers
> currently.
>
>
Sure I know that, but to replace the whole system vm just to update glibc,
haproxy or what have you seems a bit extreme.

My intention for this thread was to figure out if we can provide cloudstack
users a way to ensure their system vms are kept up to date.
It should be optional so that more advanced users or those without internet
etc. don't run into issues because of it, while still keeping all those
small clouds that 'just works' safe and secure.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 10:36 AM, Nux!  wrote:

> Hi Erik,
>
> Legit worry point.
>
> IMHO the updates of the VR and so on should be the job of whoever runs the
> cloud, just like it's the same person's job to keep the HVs up to date.
>

Well, to some point I agree, but we should do our best to reduce that need
IMHO. The hypervisor is under your control and is something you supply to
CloudStack.
The only reference a lot of people have to the system vm is that they do
the initial seeding (from a provided template in most cases), and that is
that.

In general you don't need to do much inside the system vms, and I fear that
there are a lot of clouds out there with uber old system vms because people
don't generally think about how they are exposed.

At minimum we should write something about it, e.g. "How to make sure your
system vm is up to date and secure" and possibly provide some options on
how to achieve that. Currently I don't think there's a single sign that you
have to worry about it at all.



>

I'm sure it's possible to get all the VRs registered in some sort of
> ansible/puppet thingy and keep track of them this way.
>
>
Sure, atleast ansible support dynamic inventory.


> Regarding up to date VM templates, I think part of the problem is solved
> as Jenkins is building 4.6 frequently:
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> It might just be a matter of uploading those to cloudstack.apt-get.eu.
>

That would solve 2)

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Remi Bergsma]

Hi Erik,

The version might not change, but Jenkins builds new ones every night with 
latest OS patches:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

Option 1) and 3) will work once we allow more space on the systemvm template 
for it to actually handle installing stuff. You then also assume they have 
internet acces, which may not be true.

Option 2) I think we already do that?

You can always upload a new template and replace it (a global config like 
systemvm.minversion or so exists). This will require to reboot all routers 
currently.

Regards,
Remi





On 22/02/16 09:53, "Erik Weber"  wrote:

>As of 4.6 or so, we don't really need to distribute new system vm templates
>all that often, and that is great for upgrades, but less so from a security
>perspective.
>
>With the current approach we ship old system vm templates, with out of date
>packages, and there is currently no good out of the box way to handle that.
>
>There is a few ways to handle it, including, but not limited to:
>
>1) Introduce a configuration value that specifies if you want to run
>apt-get update && apt-get upgrade on boot. This slows down deployments and
>will only get worse as times passes and there are more packages to update.
>An alternative is to specify a list of packages we _HAVE_ to keep updated
>and only update those.
>
>2) Package new system vms for all releases, but not bump the version number
>(or introduce a patch version number). This is ment to ensure that new
>cloud deployments are somewhat up to date, but won't update existing ones
>nor ensure that the deployment is kept up to date.
>
>3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
>the downside is that you risk having some downtime for certain services.
>
>4) A combination of the previous 3.
>
>And most likely other options I haven't thought of.
>
>I feel we need to address this somehow or else we risk ending up as a very
>negative headliner when the right (or wrong) bug/exploit gets out and takes
>down a bunch of clouds..
>
>-- 
>Erik

Re: [DISCUSS] Keeping system vms up to date

[Nux!]

Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the 
cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of 
ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as 
Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Erik Weber" 
> To: "dev" 
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> As of 4.6 or so, we don't really need to distribute new system vm templates
> all that often, and that is great for upgrades, but less so from a security
> perspective.
> 
> With the current approach we ship old system vm templates, with out of date
> packages, and there is currently no good out of the box way to handle that.
> 
> There is a few ways to handle it, including, but not limited to:
> 
> 1) Introduce a configuration value that specifies if you want to run
> apt-get update && apt-get upgrade on boot. This slows down deployments and
> will only get worse as times passes and there are more packages to update.
> An alternative is to specify a list of packages we _HAVE_ to keep updated
> and only update those.
> 
> 2) Package new system vms for all releases, but not bump the version number
> (or introduce a patch version number). This is ment to ensure that new
> cloud deployments are somewhat up to date, but won't update existing ones
> nor ensure that the deployment is kept up to date.
> 
> 3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
> the downside is that you risk having some downtime for certain services.
> 
> 4) A combination of the previous 3.
> 
> And most likely other options I haven't thought of.
> 
> I feel we need to address this somehow or else we risk ending up as a very
> negative headliner when the right (or wrong) bug/exploit gets out and takes
> down a bunch of clouds..
> 
> --
> Erik

[DISCUSS] Keeping system vms up to date

[Erik Weber]

As of 4.6 or so, we don't really need to distribute new system vm templates
all that often, and that is great for upgrades, but less so from a security
perspective.

With the current approach we ship old system vm templates, with out of date
packages, and there is currently no good out of the box way to handle that.

There is a few ways to handle it, including, but not limited to:

1) Introduce a configuration value that specifies if you want to run
apt-get update && apt-get upgrade on boot. This slows down deployments and
will only get worse as times passes and there are more packages to update.
An alternative is to specify a list of packages we _HAVE_ to keep updated
and only update those.

2) Package new system vms for all releases, but not bump the version number
(or introduce a patch version number). This is ment to ensure that new
cloud deployments are somewhat up to date, but won't update existing ones
nor ensure that the deployment is kept up to date.

3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
the downside is that you risk having some downtime for certain services.

4) A combination of the previous 3.

And most likely other options I haven't thought of.

I feel we need to address this somehow or else we risk ending up as a very
negative headliner when the right (or wrong) bug/exploit gets out and takes
down a bunch of clouds..

-- 
Erik

Re: VM state = Expunging

[Sanjeev N]

Expunging is the final state of the vm. We don't have expunged state.

On Mon, Feb 22, 2016 at 12:51 PM, Daan Hoogland 
wrote:

> I ran into that as well, a while ago. IMNSHO the VM record should be
> deleted after the state expunging, so a state of expunged would never make
> sense. Deabatable of course.
>
> On Mon, Feb 22, 2016 at 7:03 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Hi,
> >
> > Is anyone able to confirm that when you delete and expunge a VM in 4.9
> that
> > the state finishes with "Expunging" instead of "Expunged".
> >
> > I don't think it really "harms" much as the removed column is populated
> > (so, for example, the GUI doesn't show these VMs), but it does seem a bit
> > odd (and front-ends that are waiting for the "Expunged" state to show up
> > won't see it).
> >
> > Thanks,
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>
>
>
> --
> Daan
>