RE: CloudStack Quality Process
Not dominated, majority presence -Original Message- From: Stephen Turner [mailto:stephen.tur...@citrix.com] Sent: Monday, January 12, 2015 3:30 AM To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process 17:00 is the earliest I can do this week, although I realise that's getting late in India and I'm not trying to have a veto. Who's planning to come this week? Last week, it seemed a bit quiet and Citrix- dominated [*], although we still had a good session. Will it pick up again now everyone's back from the Christmas holidays? [*] I know we're representing ourselves not our companies, but it's nice to have a diversity of perspectives. -- Stephen Turner -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] Sent: 12 January 2015 10:21 To: dev@cloudstack.apache.org Subject: Re: CloudStack Quality Process Can this be moved earlier by an hour to 16GMT ? -abhi On 12-Jan-2015, at 1:36 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: People, I can't make it wednesday 14 17 GMT.. I have a meeting at 17:30 GMT and will be driving there before. Please make a recording for me? regards, -- Daan Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software- engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack- training/ 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. 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.
RE: CloudStack Quality Process
Zealand (toll-free): 0 800 47 0011 New Zealand: +64 (0) 9 280 6302 Norway (toll-free): 800 69 046 Norway: +47 75 80 32 07 Panama (toll-free): 00 800 226 8832 Peru (toll-free): 0 800 54682 Philippines (toll-free): 1 800 1651 0716 Poland (toll-free): 00 800 1213979 Portugal (toll-free): 800 784 461 Romania (toll-free): 0 800 410 029 Russian Federation (toll-free): 810 800 29674011 Saudi Arabia (toll-free): 800 844 3633 Singapore (toll-free): 800 101 2992 South Africa (toll-free): 0 800 983 867 Spain (toll-free): 800 900 582 Spain: +34 911 82 9906 Sweden (toll-free): 020 980 772 Sweden: +46 (0) 852 500 186 Switzerland (toll-free): 0 800 740 393 Switzerland: +41 (0) 435 0167 13 Taiwan (toll-free): 0 800 666 854 Thailand (toll-free): 001 800 658 131 Turkey (toll-free): 00 800 4488 23683 Ukraine (toll-free): 0 800 50 0641 United Arab Emirates (toll-free): 800 044 40439 United Kingdom (toll-free): 0 808 168 0229 United Kingdom: +44 (0) 20 7151 1853 United States (toll-free): 1 877 309 2073 Uruguay (toll-free): 000 413 598 4110 Viet Nam (toll-free): 120 32 153 Access Code: 759-444-232 Audio PIN: Shown after joining the meeting Meeting ID: 759-444-232 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -- Stephen Turner -Original Message- From: Stephen Turner [mailto:stephen.tur...@citrix.com] Sent: 16 December 2014 13:03 To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process Were we planning to have another meeting at the same time tomorrow (2014- 12-17T17:00Z)? Animesh, can you set up a GTM again? (Hoping that no-one's going to complain about my date format if I follow ISO 8601). -- Stephen Turner -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 11 December 2014 07:23 To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Don’t worry the first meeting went all over and the wiki needs a lot of cleanup and capture of discussion that we had. Stay tuned -Original Message- From: Rajani Karuturi [mailto:raj...@apache.org] Sent: Wednesday, December 10, 2014 8:48 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Thanks for sharing the notes. Sorry, I couldn't make it this time. Will definitely plan to join the next meeting. ~Rajani On Thu, Dec 11, 2014 at 1:27 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Folks We had good initial session this morning and we have started a public wiki [1] to allow us to collaborate. It is a scratch pad for start and we all will refine it as we go along. The link to recording and the chat log from today's meeting are also referenced in the wiki. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+P ro cess+Improvement+Initiative -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, December 10, 2014 9:05 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process The meeting is on ... -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, December 09, 2014 8:56 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Yes I am planning to record the GTM -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Tuesday, December 09, 2014 6:59 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Is it possible to record the meeting? Maybe we can post it so others can view it if they are not able to attend (or only become interested after the first couple meetings and wants to catch up)? Will On Dec 9, 2014 9:52 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll
[OFFLINE] Animesh offline from 12/18 - 12/28
Happy holidays everyone. I will be offline from 12/18 - 12/28. Thanks Animesh
RE: [OFFLINE] Animesh offline from 12/18 - 12/28
I wish I could take that much time off. -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Monday, December 15, 2014 4:07 PM To: dev@cloudstack.apache.org Subject: Re: [OFFLINE] Animesh offline from 12/18 - 12/28 Dec 2018 to Dec 2028? :-D Happy xmas new year -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Animesh Chaturvedi animesh.chaturv...@citrix.com To: dev@cloudstack.apache.org Sent: Monday, 15 December, 2014 23:07:38 Subject: [OFFLINE] Animesh offline from 12/18 - 12/28 Happy holidays everyone. I will be offline from 12/18 - 12/28. Thanks Animesh
RE: CloudStack Quality Process
The meeting is on ... -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, December 09, 2014 8:56 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Yes I am planning to record the GTM -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Tuesday, December 09, 2014 6:59 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Is it possible to record the meeting? Maybe we can post it so others can view it if they are not able to attend (or only become interested after the first couple meetings and wants to catch up)? Will On Dec 9, 2014 9:52 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 3281 Canada: +1 (647) 497-9380 Chile (toll-free): 800 395 146 China (toll-free): 4008 866154 Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): 800 500453 Denmark (toll-free): 8025 0919 Denmark: +45 (0) 69 91 84 58 Finland (toll-free): 0 800 94473 Finland: +358 (0) 931 58 1773 France (toll-free): 0 805 541 052 France: +33 (0) 170 950 590 Germany (toll-free): 0 800 184 4230 Germany: +49 (0) 692 5736 7300 Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): 001 803 020 2563 Ireland (toll-free): 1 800 818 263 Ireland: +353 (0) 15 133 006 Israel (toll-free): 1 809 388 020 Italy (toll-free): 800 792289 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 242 200 Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): 800 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 800 123 8367 Netherlands (toll-free): 0 800 020 0178 Netherlands: +31 (0) 208 080 759 New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 9579 Norway (toll-free): 800 69 055 Norway: +47 21 04 30 59 Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 800 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 Spain: +34 931 76 1534 Sweden (toll-free): 020 794 545 Sweden: +46 (0) 852 500 691 Switzerland (toll-free): 0 800 000 452 Switzerland: +41 (0) 435 0026 89 Taiwan (toll-free): 0 800 666 846 Thailand (toll-free): 001 800 852 2442 Turkey (toll-free): 00 800 4488 29001 Ukraine (toll-free): 0 800 50 4691 United Arab Emirates (toll-free): 800 044 40444 United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20 7151 1817 United States (toll-free): 1 877 309 2070 Uruguay (toll-free): 000 405 4459 Viet Nam (toll-free): 120 32 148 Access Code: 285-394-368 Audio PIN: Shown after joining the meeting Meeting ID: 285-394-368 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: Tuesday, December 09, 2014 11:16 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Based on Doodle. Meeting is schedule for Dec 10th, 17h00 UTC. freenode: #cloudstack-meeting unless someone have a GTM. Regards, On Mon, Dec 8, 2014 at 10:41 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: When do we call the result of the doodle? wait for wednesday? On Sat, Dec 6, 2014 at 5:46 PM, Chip Childers chipchild...@apache.org wrote: Thanks for listening to my concerns folks... and I'll be rooting for those of you that are doing to come up with some better practices for the community to adopt! On Fri, Dec 5, 2014 at 5:07
RE: CloudStack Quality Process
Folks We had good initial session this morning and we have started a public wiki [1] to allow us to collaborate. It is a scratch pad for start and we all will refine it as we go along. The link to recording and the chat log from today's meeting are also referenced in the wiki. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Process+Improvement+Initiative -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, December 10, 2014 9:05 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process The meeting is on ... -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, December 09, 2014 8:56 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Yes I am planning to record the GTM -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Tuesday, December 09, 2014 6:59 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Is it possible to record the meeting? Maybe we can post it so others can view it if they are not able to attend (or only become interested after the first couple meetings and wants to catch up)? Will On Dec 9, 2014 9:52 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 3281 Canada: +1 (647) 497-9380 Chile (toll-free): 800 395 146 China (toll-free): 4008 866154 Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): 800 500453 Denmark (toll-free): 8025 0919 Denmark: +45 (0) 69 91 84 58 Finland (toll-free): 0 800 94473 Finland: +358 (0) 931 58 1773 France (toll-free): 0 805 541 052 France: +33 (0) 170 950 590 Germany (toll-free): 0 800 184 4230 Germany: +49 (0) 692 5736 7300 Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): 001 803 020 2563 Ireland (toll-free): 1 800 818 263 Ireland: +353 (0) 15 133 006 Israel (toll-free): 1 809 388 020 Italy (toll-free): 800 792289 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 242 200 Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): 800 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 800 123 8367 Netherlands (toll-free): 0 800 020 0178 Netherlands: +31 (0) 208 080 759 New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 9579 Norway (toll-free): 800 69 055 Norway: +47 21 04 30 59 Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 800 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 Spain: +34 931 76 1534 Sweden (toll-free): 020 794 545 Sweden: +46 (0) 852 500 691 Switzerland (toll-free): 0 800 000 452 Switzerland: +41 (0) 435 0026 89 Taiwan (toll-free): 0 800 666 846 Thailand (toll-free): 001 800 852 2442 Turkey (toll-free): 00 800 4488 29001 Ukraine (toll-free): 0 800 50 4691 United Arab Emirates (toll-free): 800 044 40444 United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20 7151 1817 United States (toll-free): 1 877 309 2070 Uruguay (toll-free): 000 405 4459 Viet Nam (toll-free): 120 32 148 Access Code: 285-394-368 Audio PIN: Shown after joining the meeting Meeting ID: 285-394-368 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: Tuesday, December 09, 2014 11:16
RE: CloudStack Quality Process
Don’t worry the first meeting went all over and the wiki needs a lot of cleanup and capture of discussion that we had. Stay tuned -Original Message- From: Rajani Karuturi [mailto:raj...@apache.org] Sent: Wednesday, December 10, 2014 8:48 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Thanks for sharing the notes. Sorry, I couldn't make it this time. Will definitely plan to join the next meeting. ~Rajani On Thu, Dec 11, 2014 at 1:27 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Folks We had good initial session this morning and we have started a public wiki [1] to allow us to collaborate. It is a scratch pad for start and we all will refine it as we go along. The link to recording and the chat log from today's meeting are also referenced in the wiki. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Pro cess+Improvement+Initiative -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, December 10, 2014 9:05 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process The meeting is on ... -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, December 09, 2014 8:56 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Yes I am planning to record the GTM -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Tuesday, December 09, 2014 6:59 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Is it possible to record the meeting? Maybe we can post it so others can view it if they are not able to attend (or only become interested after the first couple meetings and wants to catch up)? Will On Dec 9, 2014 9:52 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 3281 Canada: +1 (647) 497-9380 Chile (toll-free): 800 395 146 China (toll-free): 4008 866154 Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): 800 500453 Denmark (toll-free): 8025 0919 Denmark: +45 (0) 69 91 84 58 Finland (toll-free): 0 800 94473 Finland: +358 (0) 931 58 1773 France (toll-free): 0 805 541 052 France: +33 (0) 170 950 590 Germany (toll-free): 0 800 184 4230 Germany: +49 (0) 692 5736 7300 Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): 001 803 020 2563 Ireland (toll-free): 1 800 818 263 Ireland: +353 (0) 15 133 006 Israel (toll-free): 1 809 388 020 Italy (toll-free): 800 792289 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 242 200 Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): 800 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 800 123 8367 Netherlands (toll-free): 0 800 020 0178 Netherlands: +31 (0) 208 080 759 New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 9579 Norway (toll-free): 800 69 055 Norway: +47 21 04 30 59 Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 800 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 Spain: +34 931 76 1534 Sweden (toll-free): 020 794 545 Sweden: +46 (0) 852 500 691 Switzerland (toll-free): 0 800 000 452 Switzerland: +41 (0) 435 0026 89 Taiwan (toll-free): 0 800 666
RE: CloudStack Quality Process
I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 3281 Canada: +1 (647) 497-9380 Chile (toll-free): 800 395 146 China (toll-free): 4008 866154 Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): 800 500453 Denmark (toll-free): 8025 0919 Denmark: +45 (0) 69 91 84 58 Finland (toll-free): 0 800 94473 Finland: +358 (0) 931 58 1773 France (toll-free): 0 805 541 052 France: +33 (0) 170 950 590 Germany (toll-free): 0 800 184 4230 Germany: +49 (0) 692 5736 7300 Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): 001 803 020 2563 Ireland (toll-free): 1 800 818 263 Ireland: +353 (0) 15 133 006 Israel (toll-free): 1 809 388 020 Italy (toll-free): 800 792289 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 242 200 Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): 800 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 800 123 8367 Netherlands (toll-free): 0 800 020 0178 Netherlands: +31 (0) 208 080 759 New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 9579 Norway (toll-free): 800 69 055 Norway: +47 21 04 30 59 Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 800 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 Spain: +34 931 76 1534 Sweden (toll-free): 020 794 545 Sweden: +46 (0) 852 500 691 Switzerland (toll-free): 0 800 000 452 Switzerland: +41 (0) 435 0026 89 Taiwan (toll-free): 0 800 666 846 Thailand (toll-free): 001 800 852 2442 Turkey (toll-free): 00 800 4488 29001 Ukraine (toll-free): 0 800 50 4691 United Arab Emirates (toll-free): 800 044 40444 United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20 7151 1817 United States (toll-free): 1 877 309 2070 Uruguay (toll-free): 000 405 4459 Viet Nam (toll-free): 120 32 148 Access Code: 285-394-368 Audio PIN: Shown after joining the meeting Meeting ID: 285-394-368 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: Tuesday, December 09, 2014 11:16 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Based on Doodle. Meeting is schedule for Dec 10th, 17h00 UTC. freenode: #cloudstack-meeting unless someone have a GTM. Regards, On Mon, Dec 8, 2014 at 10:41 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: When do we call the result of the doodle? wait for wednesday? On Sat, Dec 6, 2014 at 5:46 PM, Chip Childers chipchild...@apache.org wrote: Thanks for listening to my concerns folks... and I'll be rooting for those of you that are doing to come up with some better practices for the community to adopt! On Fri, Dec 5, 2014 at 5:07 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Agreed -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Thursday, December 04, 2014 2:41 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process I am speaking as a committer who has limited insight into the 'correct' way to do this via Apache (so be gentle). :) I like the idea of a wiki page to help get everyone on the same page and to track the consensus as we move forward... I also agree that it is hard to come to a consensus on the list because it is really hard to have a constructive conversation on here in a timely manner where the different voices can be heard. I think it would be interesting to schedule sessions/meetings on the list so any interested party can join. These sessions/meetings would happen in a format like IRC where the transcript of the session can be later posted to the list as well
RE: CloudStack Quality Process
Yes I am planning to record the GTM -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Tuesday, December 09, 2014 6:59 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Is it possible to record the meeting? Maybe we can post it so others can view it if they are not able to attend (or only become interested after the first couple meetings and wants to catch up)? Will On Dec 9, 2014 9:52 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I can setup a GTM since it is free for Citrix. Here are the details. 1. Please join my meeting. https://www1.gotomeeting.com/join/285394368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0008 Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 191 358 Australia: +61 2 9091 7603 Austria (toll-free): 0 800 080061 Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 81388 Belgium: +32 (0) 28 08 4372 Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 3281 Canada: +1 (647) 497-9380 Chile (toll-free): 800 395 146 China (toll-free): 4008 866154 Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): 800 500453 Denmark (toll-free): 8025 0919 Denmark: +45 (0) 69 91 84 58 Finland (toll-free): 0 800 94473 Finland: +358 (0) 931 58 1773 France (toll-free): 0 805 541 052 France: +33 (0) 170 950 590 Germany (toll-free): 0 800 184 4230 Germany: +49 (0) 692 5736 7300 Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): 001 803 020 2563 Ireland (toll-free): 1 800 818 263 Ireland: +353 (0) 15 133 006 Israel (toll-free): 1 809 388 020 Italy (toll-free): 800 792289 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 242 200 Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): 800 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 800 123 8367 Netherlands (toll-free): 0 800 020 0178 Netherlands: +31 (0) 208 080 759 New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 9579 Norway (toll-free): 800 69 055 Norway: +47 21 04 30 59 Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 800 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 Spain: +34 931 76 1534 Sweden (toll-free): 020 794 545 Sweden: +46 (0) 852 500 691 Switzerland (toll-free): 0 800 000 452 Switzerland: +41 (0) 435 0026 89 Taiwan (toll-free): 0 800 666 846 Thailand (toll-free): 001 800 852 2442 Turkey (toll-free): 00 800 4488 29001 Ukraine (toll-free): 0 800 50 4691 United Arab Emirates (toll-free): 800 044 40444 United Kingdom (toll-free): 0 808 168 0209 United Kingdom: +44 (0) 20 7151 1817 United States (toll-free): 1 877 309 2070 Uruguay (toll-free): 000 405 4459 Viet Nam (toll-free): 120 32 148 Access Code: 285-394-368 Audio PIN: Shown after joining the meeting Meeting ID: 285-394-368 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: Tuesday, December 09, 2014 11:16 AM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Based on Doodle. Meeting is schedule for Dec 10th, 17h00 UTC. freenode: #cloudstack-meeting unless someone have a GTM. Regards, On Mon, Dec 8, 2014 at 10:41 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: When do we call the result of the doodle? wait for wednesday? On Sat, Dec 6, 2014 at 5:46 PM, Chip Childers chipchild...@apache.org wrote: Thanks for listening to my concerns folks... and I'll be rooting for those of you that are doing to come up with some better practices for the community to adopt! On Fri, Dec 5, 2014 at 5:07 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Agreed -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Thursday, December 04, 2014 2:41 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process
RE: CloudStack Quality Process
Agreed -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Thursday, December 04, 2014 2:41 PM To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process I am speaking as a committer who has limited insight into the 'correct' way to do this via Apache (so be gentle). :) I like the idea of a wiki page to help get everyone on the same page and to track the consensus as we move forward... I also agree that it is hard to come to a consensus on the list because it is really hard to have a constructive conversation on here in a timely manner where the different voices can be heard. I think it would be interesting to schedule sessions/meetings on the list so any interested party can join. These sessions/meetings would happen in a format like IRC where the transcript of the session can be later posted to the list as well as a summary of the transcript so it can be reviewed by any member who could not make the meeting. This way we keep all of the actual conversation in the list, but we also make it easier to actually have a 'conversation' at the same time. It is hard to beat real time when working through this sort of stuff. Does this make sense to others? Thoughts? Will *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Thu, Dec 4, 2014 at 5:17 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Wearing my PMC hat and with past experience on these discussions we have not made much progress on mailing list despite agreeing on the goals and have locked horns. One possibility after reading Chip's email and concerns I see is that, we create a wiki outlining the problem space, possible solution(s) and their specific pros and cons and have people collaborate. Once a general consensus is there and wiki is stable we can bring it back to the mailing list for final approval. This is open as well as requires participant a higher degree of commitment to collaborate and will be more structured. Thanks Animesh On Thu, Dec 4, 2014 at 7:24 PM, Chip Childers chipchild...@apache.org wrote: Steve, (Speaking with my PMC hat on, but not as someone that has the time to help with this process) I love the idea of moving forward with resolving some of the quality process / tooling / etc... challenges that we face as a project and community. I also love the idea that companies getting commercial value from this project are talking (as companies) about how to best support the project through either directing their employees to work on this problem, allowing those interested the time to do so, and / or offering (as Citrix did) required hardware/software resources to make improvements for the common good. Importantly, I like that the companies involved are mutually agreeing that this is for the common good. That said, I have a concern about the outline below, specifically in how the definition of approach and eventual execution are handled. The proposal of taking this off-list until there is a proposal to ratify is what I'd like to see changed. I would fully expect that a fleshed out proposal hitting the list would be met with more discussion than you would like (and perhaps even met with frustration). What has worked well for us in the past, where there is a need to have those interested in doing work to be able to focus on that work, has been to start with a call for interested parties (as you did). Then, using a combination of threads on this list and live meetings, make progress on defining the requirements and approach incrementally. Execution of any work should similarly be open and shared on this list. Throughout that process, allowing comments and openings for participants are critical. One of the things we learned about using live meetings to speed up the consensus process in the past is to make sure that while they are fantastic at allowing the participants to understand each other, it's critical to remember that (1) there are no project decisions made outside of the mailing lists and (2) that it's important to have minutes or notes from those live meetings shared with the community as a whole. Now a very real concern that some of us have is getting bogged down in arguments based on opinion, especially the drive by opinions. This issue (plus challenges with people violently agreeing with each other, yet talking past each other), is what I believe has held up meaningful progress. To deal with this, I suggest we all remember that projects at the ASF are about supporting those that DO, while giving opportunity for participation
RE: CloudStack Quality Process
having said so, I propose to set a date for our first (irc/goto) meeting; wednesday 10 december 16:00 UTC? [Animesh] Can we push it out by 1 hour to 17:00 UTC, the current time falls out on my time for dropping kids to school. If it does not work for others I can join @14:00 UTC (6:00 AM PST) On Thu, Dec 4, 2014 at 11:40 PM, Will Stevens wstev...@cloudops.com wrote: I am speaking as a committer who has limited insight into the 'correct' way to do this via Apache (so be gentle). :) I like the idea of a wiki page to help get everyone on the same page and to track the consensus as we move forward... I also agree that it is hard to come to a consensus on the list because it is really hard to have a constructive conversation on here in a timely manner where the different voices can be heard. I think it would be interesting to schedule sessions/meetings on the list so any interested party can join. These sessions/meetings would happen in a format like IRC where the transcript of the session can be later posted to the list as well as a summary of the transcript so it can be reviewed by any member who could not make the meeting. This way we keep all of the actual conversation in the list, but we also make it easier to actually have a 'conversation' at the same time. It is hard to beat real time when working through this sort of stuff. Does this make sense to others? Thoughts? Will *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Thu, Dec 4, 2014 at 5:17 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Wearing my PMC hat and with past experience on these discussions we have not made much progress on mailing list despite agreeing on the goals and have locked horns. One possibility after reading Chip's email and concerns I see is that, we create a wiki outlining the problem space, possible solution(s) and their specific pros and cons and have people collaborate. Once a general consensus is there and wiki is stable we can bring it back to the mailing list for final approval. This is open as well as requires participant a higher degree of commitment to collaborate and will be more structured. Thanks Animesh On Thu, Dec 4, 2014 at 7:24 PM, Chip Childers chipchild...@apache.org wrote: Steve, (Speaking with my PMC hat on, but not as someone that has the time to help with this process) I love the idea of moving forward with resolving some of the quality process / tooling / etc... challenges that we face as a project and community. I also love the idea that companies getting commercial value from this project are talking (as companies) about how to best support the project through either directing their employees to work on this problem, allowing those interested the time to do so, and / or offering (as Citrix did) required hardware/software resources to make improvements for the common good. Importantly, I like that the companies involved are mutually agreeing that this is for the common good. That said, I have a concern about the outline below, specifically in how the definition of approach and eventual execution are handled. The proposal of taking this off-list until there is a proposal to ratify is what I'd like to see changed. I would fully expect that a fleshed out proposal hitting the list would be met with more discussion than you would like (and perhaps even met with frustration). What has worked well for us in the past, where there is a need to have those interested in doing work to be able to focus on that work, has been to start with a call for interested parties (as you did). Then, using a combination of threads on this list and live meetings, make progress on defining the requirements and approach incrementally. Execution of any work should similarly be open and shared on this list. Throughout that process, allowing comments and openings for participants are critical. One of the things we learned about using live meetings to speed up the consensus process in the past is to make sure that while they are fantastic at allowing the participants to understand each other, it's critical to remember that (1) there are no project decisions made outside of the mailing lists and (2) that it's important to have minutes or notes from those live meetings shared with the community as a whole. Now a very real concern that some of us have is getting bogged down in arguments based on opinion, especially the drive by opinions. This issue (plus challenges with people violently agreeing with each other, yet talking past each other), is what I believe has held up meaningful progress. To deal with this, I
RE: CloudStack Quality Process
Done -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: Friday, December 05, 2014 3:57 PM To: dev@cloudstack.apache.org Subject: Re: CloudStack Quality Process Let's fixed the time off the ML: http://doodle.com/xhp57mymv7hyim55 On Fri, Dec 5, 2014 at 6:36 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: having said so, I propose to set a date for our first (irc/goto) meeting; wednesday 10 december 16:00 UTC? [Animesh] Can we push it out by 1 hour to 17:00 UTC, the current time falls out on my time for dropping kids to school. If it does not work for others I can join @14:00 UTC (6:00 AM PST) On Thu, Dec 4, 2014 at 11:40 PM, Will Stevens wstev...@cloudops.com wrote: I am speaking as a committer who has limited insight into the 'correct' way to do this via Apache (so be gentle). :) I like the idea of a wiki page to help get everyone on the same page and to track the consensus as we move forward... I also agree that it is hard to come to a consensus on the list because it is really hard to have a constructive conversation on here in a timely manner where the different voices can be heard. I think it would be interesting to schedule sessions/meetings on the list so any interested party can join. These sessions/meetings would happen in a format like IRC where the transcript of the session can be later posted to the list as well as a summary of the transcript so it can be reviewed by any member who could not make the meeting. This way we keep all of the actual conversation in the list, but we also make it easier to actually have a 'conversation' at the same time. It is hard to beat real time when working through this sort of stuff. Does this make sense to others? Thoughts? Will *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Thu, Dec 4, 2014 at 5:17 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Wearing my PMC hat and with past experience on these discussions we have not made much progress on mailing list despite agreeing on the goals and have locked horns. One possibility after reading Chip's email and concerns I see is that, we create a wiki outlining the problem space, possible solution(s) and their specific pros and cons and have people collaborate. Once a general consensus is there and wiki is stable we can bring it back to the mailing list for final approval. This is open as well as requires participant a higher degree of commitment to collaborate and will be more structured. Thanks Animesh On Thu, Dec 4, 2014 at 7:24 PM, Chip Childers chipchild...@apache.org wrote: Steve, (Speaking with my PMC hat on, but not as someone that has the time to help with this process) I love the idea of moving forward with resolving some of the quality process / tooling / etc... challenges that we face as a project and community. I also love the idea that companies getting commercial value from this project are talking (as companies) about how to best support the project through either directing their employees to work on this problem, allowing those interested the time to do so, and / or offering (as Citrix did) required hardware/software resources to make improvements for the common good. Importantly, I like that the companies involved are mutually agreeing that this is for the common good. That said, I have a concern about the outline below, specifically in how the definition of approach and eventual execution are handled. The proposal of taking this off-list until there is a proposal to ratify is what I'd like to see changed. I would fully expect that a fleshed out proposal hitting the list would be met with more discussion than you would like (and perhaps even met with frustration). What has worked well for us in the past, where there is a need to have those interested in doing work to be able to focus on that work, has been to start with a call for interested parties (as you did). Then, using a combination of threads on this list and live meetings, make progress on defining the requirements and approach incrementally. Execution of any work should similarly be open and shared on this list. Throughout that process, allowing comments and openings for participants are critical. One of the things we learned about using live meetings to speed up the consensus process in the past is to make sure that while they are fantastic at allowing
RE: CloudStack Quality Process
sub team to go hash out a proposal for how we handle the following topics within the ACS community (which can then be brought back to the larger community for ratification): * Continuous integration and test automation * Gating of commits * Overall commit workflow We are looking for volunteers to commit to being part of this team. This would imply a serious commitment. We don’t want hangers on or observers. This will entail real work and late night meetings. We’re looking for people who are serious contributors to the codebase. From Citrix, David Nalley and Animesh Chaturvedi have booth told me they’re willing to commit to this project. They’ve both managed ACS releases and have a really good view into the current process — and I know both are passionate about improving our process. From my CCC discussions, I believe there are individuals from Schuberg Philis, Shape Blue and Cloud Ops who are willing to commit to this process. If you are willing to be part of this team to drive forward our community, please reply here. Thanks, -Steve Steve Wilson VP Product Unit Manager Cloud Software Citrix @virtualsteve -- Daan
RE: 4.5.0 status
Cool, let's roll it out before the holidays. Folks I had called out in JIRA for New features and Improvements that were tagged for 4.5 but still open to update the status and move out the ones that did not make it to Future. Please take care of your issues Animesh -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Thursday, December 04, 2014 8:17 PM To: dev@cloudstack.apache.org Subject: 4.5.0 status So we have no blockers currently logged, and are down to 15 critical bugs. I am going to try and roll a 4.5.0 release candidate in the next day or so. --David
RE: review board cleanup
-Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 28, 2014 1:44 AM To: dev@cloudstack.apache.org Subject: Re: review board cleanup On 28-Nov-2014, at 2:43 pm, Rajani Karuturi raj...@apache.org wrote: Is there a way to 'force' close a review if its already submitted? Some of us can do it. I went through some of them yesterday and closed a few. There are many review requests on it which are too old and lack information. I’m not sure what to do with them. [Animesh] Call the list out here for things older than 6 months and provide a week to respond failing which we can close them out. I’ll try to close a few more today. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software- engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack- training/ 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. 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.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Saturday, October 18, 2014 2:00 AM To: dev@cloudstack.apache.org Subject: [PROPOSAL] Move to github PR only during moratorium on commit After [1] I would like to officially bring up the following proposal. [Proposal] All commits come through github PR, *even* for committers. We declare a moratorium period (agreed suspension of activity) during which direct commit to master is forbidden. Only the master RM is allowed to merge PR in master (we define a master RM). If direct commit to master is done, master RM reverts without warning. Same for 4.5 and 4.4. branches. This is drastic and I am sure some folks will not like it, but here is my justification for such a measure: [Reasons]: Our commit and release processes have so far been based on the idea that development happens on master and that a release branch is cut from master (unstable development branch). Then a different set of community members harden the release branch, QA and bring it to GA level. During that time development keeps on going in master. This is an OK process if we have the luxury of having a QA team and can cope with split personality of being developers and release managers. My point of view is that as a community we cannot afford such a split brain organization and our experience overt the last year proves my point (delayed release date, broken builds, features merged without warning...) We can avoid this by cutting a release branch from a stable one (from the start), then as you (Daan) have mentioned several times, fix bugs in the release branch and merge them back in the stable source of the release (be it master). [Animesh] Sebastian you have brought up a good point dependency on QA team from Citrix is an issue for the project. This was raised in the past as well and Alex's proposal [1] few months back using CI was in my opinion is the optimal solution. Why? Because CloudStack is a huge project and one single person cannot have the full knowledge to safely review all the code and certainly cannot scale, which CI and automation can address Keeping master stable is something no one would argue against and my point would match the original proposal from Alex. May be we can have a staging branch for master and then merging the commit only after they have passed CI into master. The proposal got derailed and delayed because as called out at that time community does not want to work with a process that has a dependency on infrastructure that is not controlled by community. David and I are working to get the hardware from Citrix into ACS infra. The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes. Also as the release goes into hardening cycle there will be a number of fixes which will not be allowed in release branch but need to be fixes for future, they should all go in master. Master is the catch all default branch and in my opinion should get fixes first. [1] http://markmail.org/thread/xoyjw2sduenlytwm Feature development need to be done outside master, period. Not only for non-committers but also for committers. And merge request need to be called. This will help review and avoid surprises. [Animesh] Completely Agreed New git workflow were proposed and shutdown, mostly calling for better CI to solve quality issues. CI will not solve our quality issues alone. We need to better police ourselves. [Animesh] I have already expressed my opinion in favor of CI To avoid long discussions, I propose this simple but drastic measure. We move all our commits to github PR until 4.5 is out, this stands for committers and non-committers, direct commits (especially to master) would be reverted immediately. Our development and release process is broken, we cannot continue like this, let's fix it. [Animesh] I followed up the release process as established by Chip for 4.2 and 4.3 release for which I was the RM and frankly I did not feel it that way other than the pain of multiple RCs. Folks may not like it but I am entitled to my opinion and I do feel part of the issues for 4.4 were self- inflicted because of pre mature code freeze and too early cherry picking. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Thursday, October 23, 2014 1:22 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: [Animesh] Sebastian you have brought up a good point dependency on QA team from Citrix is an issue for the project. This was raised in the past as well and Alex's proposal [1] few months back using CI was in my opinion is the optimal solution. Why? Because CloudStack is a huge project and one single person cannot have the full knowledge to safely review all the code and certainly cannot scale, which CI and automation can address Keeping master stable is something no one would argue against and my point would match the original proposal from Alex. May be we can have a staging branch for master and then merging the commit only after they have passed CI into master. The proposal got derailed and delayed because as called out at that time community does not want to work with a process that has a dependency on infrastructure that is not controlled by community. David and I are working to get the hardware from Citrix into ACS infra. Agree. Animesh has good point to share here. The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes. By the same logic, if we fix by default on master only, the release branch may miss out commits. At any given time, the release branch is hopefully more stable than master (since it’s getting bugfixes/hardening as Animesh shared). So, by merging release branch on master we get all those hardened changes back to master. If we fix things on release branch and keep merging the release branch on master, we fix the issue both on release branch and master branch. The only issue I see is code divergence between release branch and master branch as time passes. [Animesh] Yes that is correct and that's why we had the forward branches in 4.2 and 4.3 so that commits go into forward branches (really staging) an master and it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and created less confusion Also as the release goes into hardening cycle there will be a number of fixes which will not be allowed in release branch but need to be fixes for future, they should all go in master. Master is the catch all default branch and in my opinion should get fixes first. Agree, any fix that should not be done on release branch should go in to master. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and- build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack- training/ 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. 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.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, October 23, 2014 1:31 AM To: dev Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion
RE: [ACS45]reverting commits or branching?
That’s correct Mike, Daan master is also the release branch for 4.5 and as such you are seeing issues getting fixed there. Animesh From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Saturday, October 11, 2014 8:52 PM To: dev@cloudstack.apache.org Cc: Animesh Chaturvedi Subject: Re: [ACS45]reverting commits or branching? I think Animesh is just stating that there is a use case for developers to only fix a bug that's in the master branch. For example, a feature that's been introduced in master that someone logged a ticket for would only have a fix put in in master. If the bug is in 4.4.1 and a fix goes in, it should go into 4.4.1 first and then be ported to master, as you say, Daan. On Sat, Oct 11, 2014 at 5:07 PM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: I am stating that any bugfix should fix the bug that is out there first and hence go into the release branch first and in master second! To reassert my last statement; it is very correct! The attention that has gone into bugfixing in master should not have gone there. It should have gone into release branch and only after that merging fixes back into master should happen. On Sat, Oct 11, 2014 at 5:24 PM, Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com wrote: I am not saying that. I am saying bug fixes should remain. Your last statement is not correct every bug fix should always go in master not just release branches. Sent from my iPhone On Oct 11, 2014, at 3:58 AM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: I think we need to revert a lot, Animesh. I don't think you can say that all the commits since the 1st amount to bugfixes. At least they are not commented as such. And if so, they should have gone into 4.4, not master. On Fri, Oct 10, 2014 at 8:19 PM, Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.usmailto:da...@gnsa.us] Sent: Thursday, October 09, 2014 10:20 PM To: Daan Hoogland Cc: dev Subject: Re: [ACS45]reverting commits or branching? I agree - it makes no sense - I am working on a branch minus the latest few features. I'm not done with it, but hope to have something up by end of the weekend. [Animesh] Yes we cannot delay the release branch. David, can you confirm that the bug fixes that were committed will be there. --David On Thu, Oct 9, 2014 at 5:45 AM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: H David, since our test day last weeks a lot of commits have gone into master. I saw Wilder's report coming by a week later followed by a lot of commits again. It seems to me we should revert any commit dating October. It makes no sense waiting with branching this way. 4.4.1 is not done and needs yet another spin... agree? -- Daan -- Daan -- Daan -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.commailto:mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play™
Re: [ACS45]reverting commits or branching?
I am not saying that. I am saying bug fixes should remain. Your last statement is not correct every bug fix should always go in master not just release branches. Sent from my iPhone On Oct 11, 2014, at 3:58 AM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: I think we need to revert a lot, Animesh. I don't think you can say that all the commits since the 1st amount to bugfixes. At least they are not commented as such. And if so, they should have gone into 4.4, not master. On Fri, Oct 10, 2014 at 8:19 PM, Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.usmailto:da...@gnsa.us] Sent: Thursday, October 09, 2014 10:20 PM To: Daan Hoogland Cc: dev Subject: Re: [ACS45]reverting commits or branching? I agree - it makes no sense - I am working on a branch minus the latest few features. I'm not done with it, but hope to have something up by end of the weekend. [Animesh] Yes we cannot delay the release branch. David, can you confirm that the bug fixes that were committed will be there. --David On Thu, Oct 9, 2014 at 5:45 AM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: H David, since our test day last weeks a lot of commits have gone into master. I saw Wilder's report coming by a week later followed by a lot of commits again. It seems to me we should revert any commit dating October. It makes no sense waiting with branching this way. 4.4.1 is not done and needs yet another spin... agree? -- Daan -- Daan
RE: [ACS45]reverting commits or branching?
-Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Thursday, October 09, 2014 10:20 PM To: Daan Hoogland Cc: dev Subject: Re: [ACS45]reverting commits or branching? I agree - it makes no sense - I am working on a branch minus the latest few features. I'm not done with it, but hope to have something up by end of the weekend. [Animesh] Yes we cannot delay the release branch. David, can you confirm that the bug fixes that were committed will be there. --David On Thu, Oct 9, 2014 at 5:45 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: H David, since our test day last weeks a lot of commits have gone into master. I saw Wilder's report coming by a week later followed by a lot of commits again. It seems to me we should revert any commit dating October. It makes no sense waiting with branching this way. 4.4.1 is not done and needs yet another spin... agree? -- Daan
RE: Shellshock
While testing before release is needed but the component update process with new system template as we have now takes a long time logistically. Thanks Animesh -Original Message- From: Sheng Yang [mailto:sh...@yasker.org] Sent: Tuesday, September 30, 2014 6:08 PM To: dev@cloudstack.apache.org Subject: Re: Shellshock It's not a safe approach, because upgrade without testing may introduce other bugs, such as one bug we saw recently introduced by upgrade of openswan. I think we still need to generate template, then distribute it after testing. If we can maintain an supported Debian repo for CloudStack, then it would be much easier for upgrade. --Sheng On Tue, Sep 30, 2014 at 5:31 PM, ilya musayev ilya.mailing.li...@gmail.com wrote: Perhaps we take an approach from a different angle. Each time systemvm deployed, it mounts an ISO which contains some shell scripts that are run on first boot. We can alter the iso file and inject user specified script that will run apt-get/yum update bash or anything else user needs to do to customize the router vm to his liking. Regards ilya On 9/30/14, 4:26 PM, Adrian Lewis wrote: @John - Quite agree. It's not just scripts that need checking either. Very unsettling to have a vulnerable version of bash on every system vm, many with direct access to both the CS infrastructure as well as client VMs. All it takes is for someone to find another vector (e.g. DHCP, DNSmasq) other than a script to inject system variables and there's suddenly a MUCH bigger problem. Is there no way to simply update the version of bash included with the system vm template? At the moment it seems to be version 4.2.37 which is vulnerable (based on http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.1-7- vmware.ova). I'm not too familiar with what happens to the template as it's deployed but if I log in as root/password to the system vm template running as downloaded in VMware Workstation and 'echo $SHELL' I get '/bin/bash' even though '/bin/sh' is a symlink to '/bin/dash'. Perhaps someone is already working quietly on this but surely this should be treated as a fairly major priority? I'd far rather not have bombs in every system vm in the first place regardless of whether people think there aren't any detonators. Adrian -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: 30 September 2014 22:57 To: dev@cloudstack.apache.org Subject: Re: Shellshock I’m not worried about any specific use-case, but I’d rather not have vulnerable software running on SSVMs in general. John On Sep 30, 2014, at 2:47 PM, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: The parameters of system() function have been verified as valid IP/netmask format by script, so I don't think other parameters would be able to slip in in this case. --Sheng On Tue, Sep 30, 2014 at 8:38 AM, Go Chiba go.ch...@gmail.commailto:go.ch...@gmail.com wrote: Hi folks, By my digging, ipcalc included system() function call but debian based our system vm are using dash as system shell. So I think this shellshock concern are not directly affected to system vm cgi-bin. right? GO from my iPhone 2014/09/30 10:13、Demetrius Tsitrelis demetrius.tsitre...@citrix.commailto:demetrius.tsitre...@citrix.com のメッセージ: http://systemvm-public-ip/cgi-bin/ipcalc is a perl script. -Original Message- From: Sheng Yang [mailto:sh...@yasker.org] Sent: Monday, September 29, 2014 5:21 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Shellshock http://systemvm-public-ip/cgi-bin/ipcalc is NOT a bash script, so it's normal that it cannot be exploited. --Sheng On Fri, Sep 26, 2014 at 1:57 PM, Demetrius Tsitrelis demetrius.tsitre...@citrix.commailto:demetrius.tsitre...@citrix.com wrote: Do you mean you tried setting the USER_AGENT like in https://community.qualys.com/blogs/securitylabs/2014/09/25/qualysguar d -remote-detection-for-bash-shellshock ? -Original Message- From: Ian Duffy [mailto:i...@ianduffy.ie] Sent: Friday, September 26, 2014 6:56 AM To: CloudStack Dev Subject: Re: Shellshock Tried this against the latest system vms built on Jenkins. Didn't get a successful exploited response. Tested against http://systemvm - public-ip/cgi-bin/ipcalc On 25 Sep 2014 16:56, Abhinandan Prateek agneya2...@gmail.com wrote: After heart bleed we are Shell shocked http://www.bbc.com/news/technology-29361794 ! It may not affect cloudstack directly as it is a vulnerability that affects bash, and allows the attacker to take control of the system running bash shell. -abhi Stratosec - Secure Finance and Heathcare Clouds http://stratosec.co o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
Re: Review Request 25248: Fix NPE in case VM is started and its template does not exist anymore
On Sept. 2, 2014, 7:01 p.m., Nitin Mehta wrote: engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java, line 814 https://reviews.apache.org/r/25248/diff/1/?file=673914#file673914line814 Checking for template==null masks the whole problem. 1. Such validations should have happenned in the deployvm api layer if it comes from that api. 2. If its coming from a startvm api its perfectly fine to have the template removed since the volume already exists. 3. If you see how template is used below...if it has to 'create' a new volume the template shouldnt be removed but again the validations should be in api layer. Rohit Yadav wrote: So, I can read code too, upper layers are not passing the template so what do you propose? How may I fix this then? Nitin Mehta wrote: Firstly, check whether the issue is reproducible. Just realized that from 4.3 onwards templates have 'Inactive' state to mark it removed. Removed attribute should never be set so this exception shouldnt be hit . Check when is the removed flag set as it should be a bug(check CLOUDSTACK-5997 and backporting it already fixes that). Secondly, even if this bug doesnt exist, do a sanity check and see this kind of check is in the api which will ultimately call this method. Check if apis are missing them. But some apis might not need it like StartVm, Rebootvm where new volume is not created. Do write a util method which could be shared by all apis. I guess that should be good enough. Rohit Yadav wrote: This was for 4.3.1, I guess this is a special case and not a blocker. The issue was reproducible when say an admin removed a template where a user may be trying to create a VM and was in a wizard. I'm closing as we're not putting this for 4.3.1 release. Nitin Mehta wrote: Please punt it for 4.5. We should fix it. Is anyone of you putting a fix for 4.5 - Animesh --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25248/#review52059 --- On Sept. 2, 2014, 1:53 p.m., Rohit Yadav wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25248/ --- (Updated Sept. 2, 2014, 1:53 p.m.) Review request for cloudstack, Alena Prokharchyk, edison su, Darren Shepherd, Sebastien Goasguen, and Hugo Trippaers. Bugs: CLOUDSTACK-6945 https://issues.apache.org/jira/browse/CLOUDSTACK-6945 Repository: cloudstack-git Description --- Fixes https://issues.apache.org/jira/browse/CLOUDSTACK-6945 Diffs - engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 2fd7a52 Diff: https://reviews.apache.org/r/25248/diff/ Testing --- Builds cleanly, will throw resource not available exception when template does not exist. Thanks, Rohit Yadav
RE: issues remaining for 4.4.1
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, August 07, 2014 1:53 AM To: dev Subject: issues remaining for 4.4.1 H, have a look at https://issues.apache.org/jira/browse/CLOUDSTACK- 6358?filter=12328007 It is a disappointing 280+ list of issues with 4.4 but I think a lot of them can be marked as won't solve, future releases or resolved. [Animesh] We should not mark them as won't solve since they are still fresh. You can move them to 4.5. I am doing triage daily and looking over unassigned and finding someone to help. But you are right there are 1000+ unresolved issues (200 blocker, critical) and 1/2 of them are from prior year. We need volunteers to help triage and resolve issues. Some of really old ones can be resolved as obsolete Please help me weed through these. thanks, -- Daan
RE: [VOTE] git workflow
(Like most of the internet...) I strongly believe using cherry picks as the basic tool for (release) branch management is one of the worst choices you can make. But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1] [Animesh] Leo I don't mind moving to merging branches rather than cherry-picking for technical reasons, but I am not sure cherry-picking is to blame entirely. Using it all the time caused the pain. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3 where I was the RM. RM cannot scale if they are spending most of their time in cherry-picking or merging branches into release branch. It needs to be done when they are reasonably confident that the churn will be limited otherwise RM will get drowned in all these requests (be it cherry-pick or merge branch). And also I have used cherry-pick with -x flag which appends cherry-picked from ...' to the original commit message in order to indicate which commit this change was cherry-picked from.
RE: [VOTE] git workflow
-Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Wednesday, August 06, 2014 3:19 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] git workflow [top posting, apologies in advance] I am on vacation, so I will go straight to it :) This all discussion is not about gitflow specifically, it is about modifying our git workflow and our commit practices to something more standard that can: - ultimately help improve quality (in itself it won't but it can help lay a foundation) - provide a stable master (it keeps breaking, it has regressions, it moves really fast etc..) - help cut releases Any committer has write privileges and can do whatever it wants to the repos, so we need to get a nice big consensus on what problems we are trying to solve, and how best to get there. So let's not make this a debate of yeah or neah gitflow. A better CI is coming but it's not yet there and we have no ETA. Even with a CI infra in place, we will need commit discipline to improve quality (covertity, unitests, simulator tests). Changing our git commit practices has no cost (just emails and self discipline), so can we agree to do that first ? Here are couple high level things that I have in mind ( and I confess I have not read the entire threads on this yet and ti ma conflict with gitflow). -Master: what goes in master is only something that has been put into a release (aside from the maintenance releases fixes maybe...). Master is the base for any release branch (until we get to 4.5, master will still see some high churn to stabilize it, after 4.5 release branch is cut we should enter into a stable master mode). -Release: from the time a release branch is cut, features are only merged by RM. [Animesh] Features have to be merged into develop branch before the feature freeze date in order to make into release branch. This is not done by RM but the feature developer. Release branch should already have features that made it by the feature freeze date hot fixes are only merged by RM. the RM is responsible for the entire release process. Since he defines the scope and is the primary person responsible to check BVT for the release branch he should be able to release on-time. Major release gets merged back into master. -Devs: folks working on features and fixes are responsible to merge into the develop branch and call the RM for a merge into a release branch (this may vary with gitflow, where release branch is cut from develop) [Animesh] I want to be clear on timing for this otherwise RM cannot scale and will drown in these requests. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3. Once we have CI, it should run on every branch. -sebastien On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Edison, thank you for raising the concern about the BVT/CI. Somebody mentioned earlier that we should separate git workflow implementation from the CI effort, but I do think we have to do in in conjunction. Otherwise what is the point in introducing staging/develop branch? If there is no daily automation run verifying all the code merged from hotFixes/feature branches (and possibly reverting wrong checkins), we can as well merge the code directly to master. -Alena. On 8/6/14, 2:30 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Wednesday, August 06, 2014 12:59 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] git workflow On 8/6/14, 12:52 PM, Erik Weber terbol...@gmail.com wrote: On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Agree with you, Rohit. The changes to the git model we use, are needed indeed. But we should address only the problems that CS faces, and the main problem - quality control. The proposal should be limited just to the changes that are really needed for the CS, and that will work with the current CS model (minor maintenance releases support is a part of it) Theoretically you don't really have to change anything other than merging instead of cherry picking. That is the main issue from a release perspective. But I still think there are good reasons to do so; 1) using a well known way of handling code/releases instantly tells new contributors / committers how we work. add to the fact that there exists tools to help doing this correctly is a bonus. 2) having a known stable (atleast in theory) release as master is good practice. although not many users will be running from git, i still consider it to be good practice. 3) there is a huge belief in this thread/discussion that as long as something passes CI / BVT it is considered stable. The fact is that it is
RE: [VOTE] git workflow
+0 While this protects master with only commits which are merges from release branch and keeps it clean but the issues that we have shift to develop branch. -Original Message- From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] Sent: Thursday, July 31, 2014 3:28 AM To: dev Subject: [VOTE] git workflow Hi All, We had long discussions on the git flow. I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git- ProposedGitflowbasedCheck-inProcess and is up for a vote: Can you share your opinion on the proposal? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, ~Rajani
RE: [VOTE] git workflow
-Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Friday, August 01, 2014 7:42 AM To: dev@cloudstack.apache.org Subject: Re: [VOTE] git workflow On Aug 1, 2014, at 10:30 AM, Nate Gordon nate.gor...@appcore.com wrote: +1 On CI, I think it should run on any branch that wants to maintain quality. So master, develop, releases, hotfixes, and support. It would be awesome if I could elect to have my random other branches run CI as well, but my guess is that we would need more hardware to pull that off. Hopefully I'll have some extra hardware to donate to the cause in the next few months, but need to get everything currently on it moved somewhere else first. FWIW, a few of us are looking at a TravisCI setup to run the simulator. Assuming the tests would run quickly ( 60 minutes on travis hardware), we could have tests run on every commit for every branch mirrored on github (.I hear some of you say yeah right.). But imho that would be an ideal scenario, as folks own fork could also run the simulator automatically. Will see if we get anywhere with this. [Animesh] that will be awesome On Fri, Aug 1, 2014 at 5:37 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: On 01-Aug-2014, at 1:40 am, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Thank you, Rohit. Couple more things we have to clarify in the wiki. The doc says Developer should run the BVT on the simulator before doing a checkin², but it doesn¹t mention anything about the CI. So here are my questions: 1) CI execution * on which branches we are planning to run the CI * with what frequency Automated systems will be there for main branches such as develop, master, release etc. The frequency would vary, the best I'm able to get on my local lab is 50 mins per BVT run (advanced). For feature, bug fix, developer's personal branches developers can setup a CI with Travis, Azure (Edison says free subscription is available), AWS (free-tier) etc. at least say once a day run the BVTs on their laptop/desktop before pushing the code to their remote branch. 2) Reverting the fixes breaking the CI - are we planning to do it? If so, would it be done automatically after CI run, or developer should do it himself? I think a human should do it. In the past we've seen developer revert breaking commit(s) and reaching out to the author/community about it. Regards. -Alena. On 7/31/14, 4:28 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Comments in-line; On 31-Jul-2014, at 11:03 pm, Alena Prokharchyk alena.prokharc...@citrix.com wrote: Done, updated the wiki page with my comments. Copy/pasting here: Open items: 1) Which bugs can be submitted to develop branch directly. Document http://nvie.com/posts/a-successful-git-branching-model/ mentions that the *hotfix branch should be created for the blocker/critical bugs in the current production release. What about bugs happenning in the *release(the one that hasn't been released yet)/*develop branches ? Should we fix them directly in those branches, or should we branch out off the *release branch, fix the problem, and merge the fix to *release? As per nvie; once cut out release branches should only have bugfixes. So, bugfixes can directly land on release branch and then cherry-picked or merge to the develop branch. For bugs on develop branch, the commits can land directly on the develop branch or can be worked in a branch checked out from develop and when done merged back. In my opinion, for any case developers should not work on any of the branches (master, release, develop) directly but checkout branch and work on it and merge back (or cherry-pick or squash merge) to respective branch only when their work is complete, with unit tests and validated using unit testing and smoke tests (BVT). We should decide: for which bugs the hot fix branch should be cut, and which fixes can go directly to *develop/*release branches. This criteria has to be defined in the doc, and be based on the a) bug severity b) number of people who work on the bug - if more than one, then we cut the new branch c) feedback/review is needed for the bug d) anything else? What you suggest is fine. I think couple of areas which can qualify for bugfixes (hotfixes) would be related to security, database changes, systemvms, agent, hypervisor, network, storage, anything that could be considered a blocker. I¹m not sure but I think adopting nvie could possibly affect our release process, I would let PMC and experienced RMs to comment on this issue and if they would like any modifications to the release process? On twitter I asked @nvie if he would have any change in the nvie model, he has a short reply: https://twitter.com/nvie/status/494870892917563393 Regards, Rohit Yadav
RE: [ACS44] template upgrade code
+ Abhi -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, July 31, 2014 12:14 PM To: dev Subject: [ACS44] template upgrade code Devs, It seems there is a big problem in the 4.4 release. The templates need a new java version but the ms seems to have no logic to automatically update the templates when found in the system. Is the code from older updates never generalized, in master or easily protable from 4.3? Can anyone give me a clue? Am willing to pull my weight on this. -- Daan
Re: [ACS44] merge of forward branch
Yes that's how I did for 4.2 and 4.3 Sent from my iPhone On Jul 28, 2014, at 6:28 PM, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: Daan, 4.4-forward should contain all the commits for 4.4. So 4.4-forward itself should be able to make as 4.4, without merge back to 4.4? That's what we want to have a 4.4-forward for 4.4. future release. It's superset of current 4.4 branch. Well, probably result in a force-overwrite. But I guess how we did it in 4.3? Animesh? --Sheng On Mon, Jul 28, 2014 at 2:36 AM, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: H, I tried merging 4.4-forward back into 4.4. This leaves us with a grand big conflict. I have calculated that the number of not cherry-picked not reverted commits is 185. I will start cherry-picking them at moments $dayjob allows. and then send a mail again. don't forget to read up on the proces git-flow is based upon. We will need to start working with a branch-merge per fix instead cherry-picks in the very near future. kind regards, -- Daan
Re: [ACS44] merge of forward branch
Then what about all fixes that went into 4.4-forward if they don't get picked up that contribution will not be used at all. Sent from my iPhone On Jul 28, 2014, at 9:45 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: I don't like the idea. release (candidates) are on 4.4 On Tue, Jul 29, 2014 at 5:43 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Yes that's how I did for 4.2 and 4.3 Sent from my iPhone On Jul 28, 2014, at 6:28 PM, Sheng Yang sh...@yasker.org wrote: Daan, 4.4-forward should contain all the commits for 4.4. So 4.4-forward itself should be able to make as 4.4, without merge back to 4.4? That's what we want to have a 4.4-forward for 4.4. future release. It's superset of current 4.4 branch. Well, probably result in a force-overwrite. But I guess how we did it in 4.3? Animesh? --Sheng On Mon, Jul 28, 2014 at 2:36 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: H, I tried merging 4.4-forward back into 4.4. This leaves us with a grand big conflict. I have calculated that the number of not cherry-picked not reverted commits is 185. I will start cherry-picking them at moments $dayjob allows. and then send a mail again. don't forget to read up on the proces git-flow is based upon. We will need to start working with a branch-merge per fix instead cherry-picks in the very near future. kind regards, -- Daan -- Daan
RE: [PROPOSAL]remove 4.4-forward
Yes that’s what we did for 4.3. Merge 4.4-forward into 4.4 -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Thursday, July 24, 2014 7:48 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL]remove 4.4-forward Yep...what Wei said. :) On Thu, Jul 24, 2014 at 8:20 AM, Wei ZHOU ustcweiz...@gmail.com wrote: yes. I think 4.4-forward can be merged into 4.4 branch after 4.4.0 release, then delete it. 2014-07-24 15:08 GMT+02:00 Daan Hoogland daan.hoogl...@gmail.com: As we will probably need a 4.4.1 I will spend some tine cherry picking through 4.4-forward to get any changes we will need from there (plus test cases) I will remove 4.4-forward after I am done. As per the git flow way of working any fixes on 4.4 will be done on a per fix branch of off 4.4. please speak up if you have objections! -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
RE: [VOTE] Apache Cloudstack 4.4.0
Hugo My understanding is only binding votes are counted. Non-binding votes are informational -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Wednesday, July 02, 2014 11:50 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.4.0 Hey Mike, That is technically not the way this vote works. Release votes a a “Lazy Majority” vote. This means that the vote requires at least 3 binding +1 votes and more +1 votes than -1 votes. For the exact working see paragraphs 3.4.4 and 3.2.2 of the Apache CloudStack bylaws. Cheers, Hugo On 3 jul. 2014, at 02:13, Mike Tutkowski mike.tutkow...@solidfire.com wrote: We have at least one binding -1, so this VOTE won't pass. We should continue to test on this RC, though, as Marcus mentioned, in an effort to reduce RC spin. We also shouldn't spin up a new RC until next week as many in the U.S. are on a long weekend starting tomorrow. On Wednesday, July 2, 2014, Marcus shadow...@gmail.com wrote: -1 I'm unable to add a KVM host. It seems to be related to changes in the SshCmdHelper. The mgmt server issues an ssh check to see of the host has kvm modules installed, which it shows it does, but there is a null pointer in the SshCmdHelper and it doesn't interpret the result correctly. I saw this once, over a month ago, and commented on CLOUDSTACK-6804. They say the null pointer is fixed in CLOUDSTACK-6844, but it looks like it was committed in 4.4-forward and never pulled in to the release branch. I tested this release with cherry-picking 2ec7359b4eb501b0d9e80ed87af7a54938e9d505 from 4.4-forward. It seems to work, though the fix seems a bit hacky (sleep loop for up to 1s, waiting for null pointer to not be null), but perhaps I just don't understand the problem well enough. In the interest of reducing RC iterations, I went ahead and continued to test per the devcloud-kvm docs. So far everything looks good as far as basic deployment and built-in storage types. * Launched VPC with a default-allow network and a default-deny network * launched an nfs-based vm in default-deny and clvm based in default-allow with qcow2 template * registered vmdk template for KVM, launched a vm based on it, for both nfs and lvm * registered raw image template, launched one for nfs and lvm * set up port forward for 22 on half of vms, static nat on the other half, verified default-allow/deny worked as needed * updated acls to allow 22 into everything, logged in to all servers to verify they deployed correctly I don't believe CLOUDSTACK-6036 should block this release, FWIW. First, there's no indication from the bug that it still affects 4.4.0, second, it's not a regression, third, it didn't block the 4.3 release either, fourth, from the sound of it, the worst of the issue is that a vm is inadvertently stopped if it previously had an issue stopping and upgrade timing happens to be just right, with a fix of simply restarting the vm. On Wed, Jul 2, 2014 at 3:51 PM, Tomasz Zięba t.a.zi...@gmail.com javascript:; wrote: -1 because CLOUDSTACK-6036 2014-07-02 22:18 GMT+02:00 Daan Hoogland daan.hoogl...@gmail.com javascript:;: Hi All, I've created a 4.4.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h =refs/heads/4.4-RC20140702T2107 Commit: 379387961bd05d1f84fe2e9a1997e9ecdceef91a List of changes: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/e n/latest/ Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.0/ PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) I will ad my key to the mentioned KEYS file as soon as possible, -- Daan -- Regards, Tomasz Zięba Twitter: @TZieba LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/ -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
RE: [ACS4.4] RC1
Ok so we are good. Looking forward to VOTE thread -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, July 01, 2014 12:56 PM To: dev Subject: Re: [ACS4.4] RC1 thats the one, On Tue, Jul 1, 2014 at 8:16 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Daan Which wiki are you referring to. I am looking at this one https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Proced ure which was setup by Chip and we have followed all along. Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, July 01, 2014 5:05 AM To: dev Subject: Re: [ACS4.4] RC1 Animesh, Do you send this as a counter proposal or overriding the procedure on the wiki? That is the one I am following. On Mon, Jun 30, 2014 at 9:56 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Daan We have been following the convention for Release VOTE threads like [1] as example. [1] http://markmail.org/message/ksyv4gftcsjc4pma Thanks Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, June 30, 2014 2:23 AM To: dev Subject: [ACS4.4] RC1 This is going to be the vote thread but I read back the procedure and found that I should more explicitly ask for consent before starting the vote. 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the version I would like to release. Do we have the feeling that this is a version stable enough? More specific: Citrix QA, do you have a good confidence level with the present state of the 4.4 branch? kind regards, -- Daan -- Daan -- Daan
RE: [ANNOUNCE] Santhosh Edukulla as a committer...
Congrats Santhosh -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Monday, June 30, 2014 9:25 AM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Santhosh Edukulla as a committer... Hi All, The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh Edukulla to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Santhosh! --Alex, on behalf of the CloudStack PMC
RE: [ACS4.4] RC1
Daan We have been following the convention for Release VOTE threads like [1] as example. [1] http://markmail.org/message/ksyv4gftcsjc4pma Thanks Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, June 30, 2014 2:23 AM To: dev Subject: [ACS4.4] RC1 This is going to be the vote thread but I read back the procedure and found that I should more explicitly ask for consent before starting the vote. 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the version I would like to release. Do we have the feeling that this is a version stable enough? More specific: Citrix QA, do you have a good confidence level with the present state of the 4.4 branch? kind regards, -- Daan
RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, May 29, 2014 10:45 AM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. [Animesh] Daan to be clear you are proposing to keep the feature freeze date at Aug 19th 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan
RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze
I saw you mentioning mid august as well so there is some confusion Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, June 25, 2014 1:52 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze No certainly not, that would mean yet another bigger release and another extra shift. It is now at 19 July And I was proposing to move it forward to last 19th of june. On Wed, Jun 25, 2014 at 10:46 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, May 29, 2014 10:45 AM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. [Animesh] Daan to be clear you are proposing to keep the feature freeze date at Aug 19th 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan -- Daan
RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze
In response to Brocade I see your response feature should be done (in it's branch) by 19th july. merging and fixing issues may take to mid august that essentially means feature freeze (cutting the branch) by mid august Animesh -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, June 25, 2014 2:07 PM To: dev@cloudstack.apache.org Subject: RE: [ACS45][ACS50][PROPOSAL] move forward feature freeze I saw you mentioning mid august as well so there is some confusion Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, June 25, 2014 1:52 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze No certainly not, that would mean yet another bigger release and another extra shift. It is now at 19 July And I was proposing to move it forward to last 19th of june. On Wed, Jun 25, 2014 at 10:46 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, May 29, 2014 10:45 AM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze Seeing what objections there might be I want to amend my proposal to 1. move forward feature freeze not on the coming but on the next release. [Animesh] Daan to be clear you are proposing to keep the feature freeze date at Aug 19th 2. set feature proposal dealine for the coming release on 19th of June flames? other thoughts? Daan On Wed, May 28, 2014 at 8:17 AM, Ritu Sabharwal rsabh...@brocade.com wrote: Thanks Daan for the clarification! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, May 27, 2014 1:56 PM To: dev Subject: Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze What I mean is that to prevent the date of oct '14 moving we need to move the feature freeze forward. so we have more time to create the release. On Tue, May 27, 2014 at 10:45 PM, Ritu Sabharwal rsabh...@brocade.com wrote: When you say release schedule shift, does it mean 4.5 release target is moved from Oct '14 to a forward date? Thanks Regards, Ritu S. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:26 AM To: dev Subject: [ACS45][ACS50][PROPOSAL] move forward feature freeze LS, When I seeing once again our release schedule shift, I think we have no option but to move feature freeze for the next release forward. This is the only way it seems we can reduce the complexity of the total sum of changes. Therefore it is the only way we can prevent lapsing even more in time without risking reduced quality of our next release. So I propose to move feature freeze forward by a month to be at the 19th of June (instead of July). I don't think we need to strictly move code freeze forward as well but vigilance onto added features will be necessary. -- Daan -- Daan -- Daan -- Daan
RE: [ACS44] are we RC-ready?
84 is a bug number to call RC ready unless the issues are not really critical -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, June 16, 2014 7:11 AM To: dev Subject: [ACS44] are we RC-ready? s far as I can tell the only remaining blocker issue has been fixed last week. There are 84 criticals. Do we feel we are RC ready as we are or are some of those critical to critical to go and release? If so, what needs to be done to get there. Please respond promptly or show yourself on #cloudstack- meeting in 50 minutes. with kind regards and loads of gratitude, -- Daan
RE: [DISCUSS] Release 4.4
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, June 12, 2014 12:27 AM To: dev Subject: Re: [DISCUSS] Release 4.4 Why would we need that in a mail to dev@ Animesh? It is on the release dashboard. [Animesh] I wish everyone would look at the dashboard but I think very few do. As for the bulk edit; I like your style but I like to give each edit a personal note. So I edit blockers asking specific questions. [Animesh] That’s fine but RM got limited time, If you can scale doing that I have no objection. On Thu, Jun 12, 2014 at 12:43 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Yes we cannot cancel the release. IMHO we started the 4.4-forward branch way early. I had created the forward branch for 4.2 and 4.3 only after first RC because up until RC we have always seen a lot of code churn and I did not think RM can scale with all the cherry-picks given that RM has to focus on the big picture. We need a daily list of blockers/critical I can set up a filter and subscription that will forward to dev mailing list automatically. We should also cc folks whom we are expecting to respond as we get lots of email on dev and follow up may not get noticed. One other thing that I used to do was setup a JIRA query for all the open Blocker and critical issues that have not been updated in last 7 day and do a BULK EDIT and ask for status or follow up. Thanks Animesh -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Wednesday, June 11, 2014 9:37 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Release 4.4 Yeah, I am concerned about 4.4 getting farther behind schedule, as well, but I agree with David that we should not cancel it. I know it might be a pain, but I wonder if the RM would be willing to nag people every few days (just an e-mail to dev@) about the current list of blockers and their progress and to see if people need help and others might be willing and able to do so. On Wed, Jun 11, 2014 at 10:08 AM, David Nalley da...@gnsa.us wrote: On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers h...@apache.org wrote: Hey all, I’m getting somewhat concerned about the 4.4 release. We don’t seems to be able to get the 4.4 branch in shape for a release candidate and meanwhile master is diverging further and further. We also know that once we hit the RC phase we will probably need a sizable number of iterations to eventually ship the release. Based on past experience, if we keep up like this we will have another release that will actually be released way after the feature freeze for the next release (July 18). Probably leaving us in the same bad spot for the next release. I tried to come up with a number of solutions that could rectify the situation and help the release move forward, but i can’t think of any. Save for some options that might be considered extreme ideas. One the the more prominent ideas in my mind at the moment is skipping the 4.4 release all together and combine it with the next planned release (whether its 5.0 or 4.5). This would require a community effort to focus on quality in the next month and basically freeze the master for features and have a community wide push for quality to get the next release out on schedule. But before i go on and shout out even more drastic ideas, what do you think about the current 4.4 release. How close do you feel that we are to having a releasable product? So this sounds very familiar to a discussion we had in 4.1 or 4.2 timeframes. (I may have even been one of the folks proposing similar ideas, I don't recall) To save you some reading I am -1 on the idea of canceling 4.4. (though really - anyone can propose a release and ask for votes, we have adopted a bit more rigor, but that structure isn't demanded.) Here's the issues I see: 1. We set the expectation that 4.4 is coming; people worked hard to get features in, and our users are waiting on it. 2. We may not be perfect from a schedule perspective, but giving up on a release is a pretty negative thing to do - whats the reaction going to be? 3. Do you think we are in a position to make 4.5 any better? Speaking very frankly, I worry that we are not. I don't think that we have either the tooling or the social desire at present to make significant strides here. We don't dictate the priorities for individual developers. It might be a different story if we were in a corporate shop and could control what folks work on, it might be a different story. --David -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview
RE: [PROPOSAL] irc meeting for release 4.4
-Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 5:37 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] irc meeting for release 4.4 On Jun 12, 2014, at 2:33 PM, Pierre-Luc Dion pd...@cloudops.com wrote: +1 I feel clue less for doing the release-notes about what new features will be in 4.4, this would be a good time to poke around. [Animesh] Every release has a filter for new features and improvements. Here is one for 4.4 that I had setup a while back https://issues.apache.org/jira/issues/?filter=12326986 Pierre-Luc, this is very good point. Apparently there are no new features in 4.4, because developers don't care to tell you what they are. So why is it so difficult to release software that has no new features ? Yet bunch of bugs are introduced. Seems to me, that's what we do, we introduce bugs in perfect software without adding functionality. On Thu, Jun 12, 2014 at 7:49 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: H, I would like to have an irc meeting on a weekly basis from now until we have 4.4 out. agenda: - code quality - blockers - other issues (count and triaging) - actual release work (left) Are there any people that feel, like me, this would help us keep the motion towards releasing going? my idea is to do it on monday around 15:00 UTC -- Daan
RE: [PROPOSAL] irc meeting for release 4.4
-Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Thursday, June 12, 2014 2:04 PM To: dev@cloudstack.apache.org Subject: RE: [PROPOSAL] irc meeting for release 4.4 -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, June 12, 2014 5:37 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] irc meeting for release 4.4 On Jun 12, 2014, at 2:33 PM, Pierre-Luc Dion pd...@cloudops.com wrote: +1 I feel clue less for doing the release-notes about what new features will be in 4.4, this would be a good time to poke around. [Animesh] Every release has a filter for new features and improvements. Here is one for 4.4 that I had setup a while back https://issues.apache.org/jira/issues/?filter=12326986 [Animesh] 9 of these issues are still open and I sent BULK EDIT reminder to move them out. Pierre-Luc, this is very good point. Apparently there are no new features in 4.4, because developers don't care to tell you what they are. So why is it so difficult to release software that has no new features ? Yet bunch of bugs are introduced. Seems to me, that's what we do, we introduce bugs in perfect software without adding functionality. On Thu, Jun 12, 2014 at 7:49 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: H, I would like to have an irc meeting on a weekly basis from now until we have 4.4 out. agenda: - code quality - blockers - other issues (count and triaging) - actual release work (left) Are there any people that feel, like me, this would help us keep the motion towards releasing going? my idea is to do it on monday around 15:00 UTC -- Daan
RE: [DISCUSS] Release 4.4
Yes we cannot cancel the release. IMHO we started the 4.4-forward branch way early. I had created the forward branch for 4.2 and 4.3 only after first RC because up until RC we have always seen a lot of code churn and I did not think RM can scale with all the cherry-picks given that RM has to focus on the big picture. We need a daily list of blockers/critical I can set up a filter and subscription that will forward to dev mailing list automatically. We should also cc folks whom we are expecting to respond as we get lots of email on dev and follow up may not get noticed. One other thing that I used to do was setup a JIRA query for all the open Blocker and critical issues that have not been updated in last 7 day and do a BULK EDIT and ask for status or follow up. Thanks Animesh -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Wednesday, June 11, 2014 9:37 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Release 4.4 Yeah, I am concerned about 4.4 getting farther behind schedule, as well, but I agree with David that we should not cancel it. I know it might be a pain, but I wonder if the RM would be willing to nag people every few days (just an e-mail to dev@) about the current list of blockers and their progress and to see if people need help and others might be willing and able to do so. On Wed, Jun 11, 2014 at 10:08 AM, David Nalley da...@gnsa.us wrote: On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers h...@apache.org wrote: Hey all, I’m getting somewhat concerned about the 4.4 release. We don’t seems to be able to get the 4.4 branch in shape for a release candidate and meanwhile master is diverging further and further. We also know that once we hit the RC phase we will probably need a sizable number of iterations to eventually ship the release. Based on past experience, if we keep up like this we will have another release that will actually be released way after the feature freeze for the next release (July 18). Probably leaving us in the same bad spot for the next release. I tried to come up with a number of solutions that could rectify the situation and help the release move forward, but i can’t think of any. Save for some options that might be considered extreme ideas. One the the more prominent ideas in my mind at the moment is skipping the 4.4 release all together and combine it with the next planned release (whether its 5.0 or 4.5). This would require a community effort to focus on quality in the next month and basically freeze the master for features and have a community wide push for quality to get the next release out on schedule. But before i go on and shout out even more drastic ideas, what do you think about the current 4.4 release. How close do you feel that we are to having a releasable product? So this sounds very familiar to a discussion we had in 4.1 or 4.2 timeframes. (I may have even been one of the folks proposing similar ideas, I don't recall) To save you some reading I am -1 on the idea of canceling 4.4. (though really - anyone can propose a release and ask for votes, we have adopted a bit more rigor, but that structure isn't demanded.) Here's the issues I see: 1. We set the expectation that 4.4 is coming; people worked hard to get features in, and our users are waiting on it. 2. We may not be perfect from a schedule perspective, but giving up on a release is a pretty negative thing to do - whats the reaction going to be? 3. Do you think we are in a position to make 4.5 any better? Speaking very frankly, I worry that we are not. I don't think that we have either the tooling or the social desire at present to make significant strides here. We don't dictate the priorities for individual developers. It might be a different story if we were in a corporate shop and could control what folks work on, it might be a different story. --David -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
RE: [ACS44] 112 unpicked cherries in 4.4-forward. why?
-Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Monday, June 09, 2014 9:24 AM To: dev@cloudstack.apache.org Subject: Re: [ACS44] 112 unpicked cherries in 4.4-forward. why? On Mon, Jun 9, 2014 at 10:39 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Right - we need to decide as a community what a forward branch really means. On Monday, June 9, 2014, Koushik Das koushik@citrix.com wrote: So a bit of background reading: http://markmail.org/message/aux2yjxpudotu7qu This is when we started with the -forward branches. --David [Animesh] I had started the forward branches right after first RC because we always have tons of fixes until we are ready with RC. IMHO starting it at code freeze is too early.
FW: New Defects reported by Coverity Scan for cloudstack
Folks please check on the issues reported. -Original Message- From: scan-ad...@coverity.com [mailto:scan-ad...@coverity.com] Sent: Monday, June 09, 2014 7:37 PM Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 20 of 67 defect(s) ** CID 1222156: Value not atomically updated (ATOMICITY) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 5272 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.execute(com.cl oud.agent.api.OvsDestroyBridgeCommand)() ** CID 1222157: Dereference after null check (FORWARD_NULL) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 1097 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getNetwork(co m.xensource.xenapi.Connection, com.cloud.agent.api.to.NicTO)() /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 1088 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getNetwork(co m.xensource.xenapi.Connection, com.cloud.agent.api.to.NicTO)() /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 1088 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getNetwork(co m.xensource.xenapi.Connection, com.cloud.agent.api.to.NicTO)() ** CID 1222175: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 3025 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.execute(com.cl oud.agent.api.MigrateCommand)() ** CID 1222174: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 6347 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.execute(com.cl oud.agent.api.AttachVolumeCommand)() ** CID 1222173: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 6285 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.execute(com.cl oud.agent.api.AttachVolumeCommand)() ** CID 1222172: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 7200 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.clusterVMMet aDataSync(com.xensource.xenapi.Connection)() ** CID 1222171: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 6131 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getNfsSR(com. xensource.xenapi.Connection, com.cloud.agent.api.to.StorageFilerTO)() ** CID 1222170: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 6412 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getVMSnapsh otChainSize(com.xensource.xenapi.Connection, org.apache.cloudstack.storage.to.VolumeObjectTO, java.lang.String)() ** CID 1222169: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 6098 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getIscsiSR(com .xensource.xenapi.Connection, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, boolean)() ** CID 1222168: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 1944 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.prepareManag edStorage(com.xensource.xenapi.Connection, java.util.Map, java.lang.String, java.lang.String)() ** CID 1222167: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 7519 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.prepareNetwo rkElementCommand(com.cloud.agent.api.routing.SetNetworkACLCommand )() ** CID 1222166: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 7499 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.prepareNetwo rkElementCommand(com.cloud.agent.api.routing.SetSourceNatCommand)() ** CID 1222165: Dereference null return value (NULL_RETURNS) /plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resou rce/CitrixResourceBase.java: 4166 in com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.enableVlanNet
RE: [GIT] 4.3.0 vs 4.3.0-forward - where to commit?
-Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Wednesday, June 04, 2014 11:17 PM To: dev@cloudstack.apache.org Subject: Re: [GIT] 4.3.0 vs 4.3.0-forward - where to commit? On Jun 5, 2014, at 8:14 AM, ilya musayev ilya.mailing.li...@gmail.com wrote: Looks like few patches that i've backported to 4.3.0-forward have been dropped (dont see my commits). i am now under impression i should have commited to 4.3.0 branch. Would someone please clarify the difference between the two and where to commit when i need to backport/cherry-pick a patch? Thanks ilya Ilya, imho those -forward branches should not exist, they create a mess. If you have something to patch for the 4.3 series, just patch it in the 4.3 branch. 4.3.0, 4.3.1 etc are tags in that 4.3 branch [Animesh] Edison had merged 4.3-forward into 4.3 yesterday and I deleted 4.3-forward branch this morning
RE: [GIT] 4.3.0 vs 4.3.0-forward - where to commit?
[Animesh] Edison had merged 4.3-forward into 4.3 yesterday and I deleted 4.3-forward branch this morning So was there a lot of bug fixes that went in 4.3 during the merge ? if yes we might want to release a 4.3.1 ? [Animesh] yes there were around 170 commits that came in with this merge. Who wants to be the Release Manager?
RE: New Defects reported by Coverity Scan for cloudstack
Rajani Thanks for bringing this up, I looked at the analysis settings and I think the pattern to exclude aws code should have a leading /. I have fixed it and lets check it on the next run. We should see a significant bump up in defect density. Good job in noticing this. Thanks Animesh -Original Message- From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] Sent: Monday, June 02, 2014 11:48 PM To: dev Subject: Re: New Defects reported by Coverity Scan for cloudstack These are the approximate number of defects reported by coverity from the generated code. /awsapi/src/com/amazon/ec2 - around 4300 /awsapi/src/com/amazon/s3 - around 350 total defects - around 6500 ~Rajani On 02-Jun-2014, at 4:57 pm, Rajani Karuturi rajani.karut...@citrix.com wrote: Hi Hugo, awsapi-generated-code is excluded for the project but I still see issues reported in them. For example for file src/com/amazon/ec2/DeleteTagsResponseType.java Can you check the file exclude pattern? I think .* is missing (awsapi/src/com/amazon/.*) Fixing this might give us a better report as I see lot of them listed in these files. ~Rajani On 29-Nov-2013, at 9:28 pm, Hugo Trippaers trip...@gmail.com wrote: FYI Sent from my iPhone Begin forwarded message: From: scan-ad...@coverity.com Date: 29 november 2013 14:39:56 CET Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1116269: Nesting level does not match indentation (NESTING_INDENT_MISMATCH) /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider.j ava: 124 in com.cloud.bridge.service.controller.s3.ServiceProvider.getManagement HostId()() ** CID 1133706: Dereference after null check (FORWARD_NULL) /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db. TransactionStatus)() ** CID 1133705: Resource leak on an exceptional path (RESOURCE_LEAK) /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()() ** CID 1133704: SS: Unread field should be static (FB.SS_SHOULD_BE_STATIC) /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in () ** CID 1133703: Dm: Dubious method used (FB.DM_DEFAULT_ENCODING) /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/comm and/LdapImportUsersCmd.java: 197 in org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor d()() ** CID 1133702: DLS: Dead local store (FB.DLS_DEAD_LOCAL_STORE) /plugins/network-elements/juniper-contrail/src/org/apache/cloudstack /network/contrail/model/VirtualMachineModel.java: 119 in org.apache.cloudstack.network.contrail.model.VirtualMachineModel.bui ldServiceInstance(org.apache.cloudstack.network.contrail.model.Model Controller, java.lang.String)() _ ___ To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
RE: New Defects reported by Coverity Scan for cloudstack
While we should wait for the next run for actual results but I am expecting the defect density as reported by Coverity to drop down from 6.4 to about 3.4 after excluding AWSAPI generated code. Animesh -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, June 04, 2014 3:56 PM To: dev@cloudstack.apache.org Subject: RE: New Defects reported by Coverity Scan for cloudstack Rajani Thanks for bringing this up, I looked at the analysis settings and I think the pattern to exclude aws code should have a leading /. I have fixed it and lets check it on the next run. We should see a significant bump up in defect density. Good job in noticing this. Thanks Animesh -Original Message- From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] Sent: Monday, June 02, 2014 11:48 PM To: dev Subject: Re: New Defects reported by Coverity Scan for cloudstack These are the approximate number of defects reported by coverity from the generated code. /awsapi/src/com/amazon/ec2 - around 4300 /awsapi/src/com/amazon/s3 - around 350 total defects - around 6500 ~Rajani On 02-Jun-2014, at 4:57 pm, Rajani Karuturi rajani.karut...@citrix.com wrote: Hi Hugo, awsapi-generated-code is excluded for the project but I still see issues reported in them. For example for file src/com/amazon/ec2/DeleteTagsResponseType.java Can you check the file exclude pattern? I think .* is missing (awsapi/src/com/amazon/.*) Fixing this might give us a better report as I see lot of them listed in these files. ~Rajani On 29-Nov-2013, at 9:28 pm, Hugo Trippaers trip...@gmail.com wrote: FYI Sent from my iPhone Begin forwarded message: From: scan-ad...@coverity.com Date: 29 november 2013 14:39:56 CET Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1116269: Nesting level does not match indentation (NESTING_INDENT_MISMATCH) /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider .j ava: 124 in com.cloud.bridge.service.controller.s3.ServiceProvider.getManageme nt HostId()() ** CID 1133706: Dereference after null check (FORWARD_NULL) /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db. TransactionStatus)() ** CID 1133705: Resource leak on an exceptional path (RESOURCE_LEAK) /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()() ** CID 1133704: SS: Unread field should be static (FB.SS_SHOULD_BE_STATIC) /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in () ** CID 1133703: Dm: Dubious method used (FB.DM_DEFAULT_ENCODING) /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/co mm and/LdapImportUsersCmd.java: 197 in org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor d()() ** CID 1133702: DLS: Dead local store (FB.DLS_DEAD_LOCAL_STORE) /plugins/network-elements/juniper-contrail/src/org/apache/cloudsta ck /network/contrail/model/VirtualMachineModel.java: 119 in org.apache.cloudstack.network.contrail.model.VirtualMachineModel.b ui ldServiceInstance(org.apache.cloudstack.network.contrail.model.Mod el Controller, java.lang.String)() _ ___ To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
RE: [DISCUSS] old forward branches
I will merge 4.3-forward into 4.3 later today. Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, May 31, 2014 1:38 PM To: dev Subject: [DISCUSS] old forward branches The older forward branches are still heavily used, while the release branches are open for bug fixes by all. I think people should no longer use older forward branches and maybe these should even be deleted. The release branches (except for 4.4) are open for all committers. I don't think we have or should have a policy on those but we run the risk of losing work this way and people running old releases won't benefit from the fixes in those forward branches. -- Daan
RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Wednesday, May 28, 2014 11:48 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
RE: [ACS44][PROPOSAL] old blocker bugs
Daan I concur with Sudha we should not change the priority of individual defects without technical reasons. The outgoing defect rate is much lower for this time of the release and certainly is a concern as you have raised. We should publish daily list of blockers and ask for status update. You can also do bulk edit for open tickets and ask for updates, I will also nudge a few folks here. thanks Animesh -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: Monday, May 26, 2014 9:21 AM To: dev@cloudstack.apache.org Subject: RE: [ACS44][PROPOSAL] old blocker bugs -1 on the proposal to lower priority of defects based on timeframe. These are blockers for features and some for release as well. We should not be modifying the priority of defect unless the original reporter or RM agrees to do so for technical reasons but not because these are not touched by anyone. As this is community based development environment, someone need to pick up and get the context and fix it which might be taking time. Understand that community should be aware of these blockers on daily basis and pick those up faster and fix them within reasonable SLAs. Unfortunately we do not have any SLAs. It is dangerous proposal to reduce priority without review of technical impact of the defect. Following process improvement would help to address this issue: - Set SLAs for a more streamlined approach towards addressing defects within reasonable timeframe. For eg blockers should be fixed within 24 hours, critical within 72 hours etc. - Send daily reports to ML on the blockers to provide more visibility (I can take up this task). - republish definition of defect priority so community is aware on the proper categorization of defects (I can publish this as well on wiki. Thanks /Sudha -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 26, 2014 5:11 AM To: dev Subject: Re: [ACS44][PROPOSAL] old blocker bugs Not well formatted but is this what you want? Key Summary Reporter Assignee Updated CLOUDSTACK-6754 SSVM not responding with S3 secondary sotre Pavan Kumar Bandarupally Min Chen 26/May/14 Actions CLOUDSTACK-6755 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster Sanjeev N Murali Reddy 23/May/14 Actions CLOUDSTACK-6623 Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server. Bharat Kumar edison su 22/May/14 Actions CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4 manasaveloori Rajesh Battala 22/May/14 Actions CLOUDSTACK-6662 New XenServer host is not activated due to no agent connection Daan Hoogland Anthony Xu 22/May/14 Actions CLOUDSTACK-6730 [Automation] test_egress_fw_rules test case failing while applying FW rule Rayees Namathponnan Rayees Namathponnan 22/May/14 Actions CLOUDSTACK-6710 [Automation] VM snapshot failing with NPE in vmware Rayees Namathponnan Likitha Shetty 21/May/14 Actions CLOUDSTACK-6602 [UI] createNetworkACL API action param value passed incorrectly Jayapal Reddy Jessica Wang 20/May/14 Actions CLOUDSTACK-6675 NPE while executing updatePortForwardingRule Chandan Purushothama Alena Prokharchyk 20/May/14 Actions CLOUDSTACK-6673 cloudstack-setup-management make a chmod 777 on /root Milamber Unassigned 19/May/14 Actions CLOUDSTACK-6644 Unable to attach Volume to a VM as a System User Chandan Purushothama edison su 19/May/14 Actions CLOUDSTACK-6599 Template/Volume URLs expiration functionality not working Nitin Mehta Nitin Mehta 19/May/14 Actions CLOUDSTACK-6674 [Automation] [DB lock] When KVM agent is alert state, agent never trying to connect back Rayees Namathponnan edison su 14/May/14 Actions CLOUDSTACK-6572 [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic Sowmya Krishnan Rajesh Battala 12/May/14 On Mon, May 26, 2014 at 2:05 PM, sebgoa run...@gmail.com wrote: On May 26, 2014, at 1:59 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: I didn't get any reactions on this second proposal and though I know I can force discussion on it by just starting to implement it as well I would really get some consent on this. Can you send the list of those blockers to the list with the name of the reporter ? On Fri, May 23, 2014 at 10:06 AM, Daan Hoogland dhoogl...@schubergphilis.com wrote: I will start implementing this on Monday. Also I would like to propose that nothing is a blocker unless it has been agreed on, on list. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: donderdag 22 mei 2014 10:08 To: dev Subject: [ACS44][PROPOSAL] old blocker bugs LS, There are several blocker bugs registered for 4.4 that have not been touched for over
RE: New Defects reported by Coverity Scan for cloudstack
Hugo Can you share the latest results? How can I get access to the reports? Animesh -Original Message- From: Hugo Trippaers [mailto:trip...@gmail.com] Sent: Friday, November 29, 2013 7:58 AM To: dev@cloudstack.apache.org Subject: Fwd: New Defects reported by Coverity Scan for cloudstack FYI Sent from my iPhone Begin forwarded message: From: scan-ad...@coverity.com Date: 29 november 2013 14:39:56 CET Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1116269: Nesting level does not match indentation (NESTING_INDENT_MISMATCH) /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider.java: 124 in com.cloud.bridge.service.controller.s3.ServiceProvider.getManagementHostId ()() ** CID 1133706: Dereference after null check (FORWARD_NULL) /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db.Tr ansactionStatus)() ** CID 1133705: Resource leak on an exceptional path (RESOURCE_LEAK) /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()() ** CID 1133704: SS: Unread field should be static (FB.SS_SHOULD_BE_STATIC) /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in () ** CID 1133703: Dm: Dubious method used (FB.DM_DEFAULT_ENCODING) /plugins/user- authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportU sersCmd.java: 197 in org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor d()() ** CID 1133702: DLS: Dead local store (FB.DLS_DEAD_LOCAL_STORE) /plugins/network-elements/juniper- contrail/src/org/apache/cloudstack/network/contrail/model/VirtualMachine Model.java: 119 in org.apache.cloudstack.network.contrail.model.VirtualMachineModel.buildSe rviceInstance(org.apache.cloudstack.network.contrail.model.ModelController, java.lang.String)() To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
Can we use In Progress state when we start working on an issue
Folks One thing as former RM I have struggled with is visibility of whether an issue is being worked upon rather than being just assigned. JIRA has a simple nice thing called In Progress please make use of it. When you start working on an issue I suggest please change the state to In Progress. It is a big reassurance to RM that the issue is being worked upon and RM can go nudge other open items. Thanks Animesh
RE: [PROPOSAL] Using continuous integration to maintain our code quality...
Hugo without putting certain rules we are not going to get out of the situation. I think it may seem draconian but stating No merges are allowed without a successful run of the automation is beneficial for everyone. It forces focus on automation and helps mitigate regression. If we run into challenges in implementing those rules like toolset not ready or infra then we would have to fix those. Animesh -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Wednesday, May 14, 2014 12:32 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Using continuous integration to maintain our code quality... Hey Alex, Nice job on getting this all done and working on some guidelines to improve quality of the overal guidelines. We discussed a lot of these things at the last CCC and i'm happy to see them here. I do have some feedback on the policy though. Specifically with the line stating No merges are allowed without a successful run of the automation. You stated yourself that the infra running the automation is being run by Citrix. Introducing this statement links our policy to Citrix in such a way that we can't commit if the citrix supplied Infra is not availalbe. That doesn't sound like a good thing. Anyway part of being a committer is the responsibility to make a correct decision when and how to commit to the central code base, this includes deciding when running automation tests is appropriate. You know i'm in favor of quality controls and i am a strong proponent of testing before committing, but each committer has his own responsibility in this and has to show he/she takes this seriously. The JIRA process is pretty good and will certainly help with keeping track of what is going on, but is not mandatory in my opinion. Also arranging for a review is not a responsibility of the developer of a piece of code. If that is necessary it is the community that fails, the really responsibility to do code reviews is with the committers, Each committer has a responsibility to monitor the changes made for potential issues, both coding and legal. (http://www.apache.org/dev/new-committers-guide.html). I'm a firm believer of providing tooling and support to help make doing the right thing as easy as possible. In my opinion the focus should be on making sure this tooling is as easy to use as possible so committers and contributors will want to use this, because it helps them instead of forcing them to use it by policy. Cheers, Hugo On 7 mei 2014, at 02:03, Alex Huang alex.hu...@citrix.com wrote: Hi All, This is something I brought up a long time ago but really didn't have the resources to get it all up and running until now. Throughout the past year, Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have been chipping away at it. At this point, we finally pull together a continuous integration setup that we can use to make sure that CloudStack master and the currently release branch are always stable. This is getting pretty close to be completed and we like to share it with the community in hopes that we can reduce/eliminate that problems we've seen with our recent releases. Currently, the physical hardware are hosted by Citrix but we'll be more than willing to donate the work to infra when that's all settled. This does require effort from the community to make a change in their development process. These steps are detailed at [1]. I like to get feedback on what everyone think about this. What have we done: - We replaced a large selection of the BVT tests to run with the simulator instead of actual hardware. This shortens the duration of each BVT run. Today, a BVT that runs tests for XenServer and KVM completes in 30-40 minutes. - We will run the new BVT on master and the current release branch on a continuous basis. - Developers can use Jenkins to ask BVT to be run on their branch so they can know it won't break the continuous integration before they merge to master and the current release branch. Please have a read and let me know what you think. --Alex [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Pro cess
RE: [ACS44] critical issue assesment
I will put a slot in my calendar for triaging bugs daily from now on. Animesh -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, May 07, 2014 1:05 AM To: dev Subject: [ACS44] critical issue assesment Friend and (yes I consider you) collegues, I would like to call on you to volunteer to judge the issues we have for 4.4 marked critical. I am (next to some other $dayjob stuff) going to try and reduce our remaining blokker issue list from 11 items to empty. You might find that some are actually blokkers. Or that some may be resolved. Please let me know if the first is true. Any one, please? thanks -- Daan
RE: 4.4 release-notes
Daan, I have added the two widgets to Dashboard based on the filters you mentioned. I did not see any specific permission in JIRA to grant you access. I guess only the owner can modify it, let me check on Atlassian documentation -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, May 05, 2014 11:53 AM To: Animesh Chaturvedi Cc: dev Subject: Re: 4.4 release-notes Animesh, Can you (give me rights to) add these filters to the release dashboard? On Fri, May 2, 2014 at 4:43 AM, Pierre-Luc Dion pd...@cloudops.com wrote: 4.4.0 Fixed Issues project = CLOUDSTACK AND type = Bug AND affectedVersion in (4.2.0, 4.2.1, 4.3.0) AND fixVersion = 4.4.0 AND resolution != \Unresolved\ ORDER BY created DESC, priority DESC, key ASC 4.4.0 Known Issues project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.4.0 OR fixVersion = 4.4.0) AND resolution is EMPTY AND level = Public ORDER BY priority DESC, key ASC -- Daan
[OFFLIST] I will be offlist from 4/17 - 5/6
Folks FYI I will be out on PTO for 2 weeks starting 4/17 Thanks Animesh
RE: 4.3 system vm template job failing in jenkins
May be this can be a quick hackathon in collab. Copying Wido and Hugo -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] Sent: Thursday, April 10, 2014 9:18 AM To: dev@cloudstack.apache.org Subject: Re: 4.3 system vm template job failing in jenkins On 10/04/14 5:24 pm, Nux! n...@li.nux.ro wrote: On 10.04.2014 11:17, Abhinandan Prateek wrote: I have tried with both the options now i.e. -qq and by removing DEBIAN_PRIORITY=critical², The pop up does not go away breaking the build job. Guys, find the solution ! -abhi This sort of works for me: (I'm downgrading to the vulnerable version) root@v-45-VM:~# aptitude install libssl1.0.0=1.0.1e-2+deb7u4 The following packages will be DOWNGRADED: libssl1.0.0 0 packages upgraded, 0 newly installed, 1 downgraded, 0 to remove and 34 not upgraded. Need to get 0 B/3,027 kB of archives. After unpacking 52.2 kB will be freed. Preconfiguring packages ... dpkg: warning: downgrading libssl1.0.0:i386 from 1.0.1e-2+deb7u6 to 1.0.1e-2+deb7u4 (Reading database ... 24354 files and directories currently installed.) Preparing to replace libssl1.0.0:i386 1.0.1e-2+deb7u6 (using .../libssl1.0.0_1.0.1e-2+deb7u4_i386.deb) ... Unpacking replacement libssl1.0.0:i386 ... Setting up libssl1.0.0:i386 (1.0.1e-2+deb7u4) ... root@v-45-VM:~# DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --force-yes libssl1.0.0 Preconfiguring packages ... (Reading database ... 24354 files and directories currently installed.) Preparing to replace libssl1.0.0:i386 1.0.1e-2+deb7u4 (using .../libssl1.0.0_1.0.1e-2+deb7u6_i386.deb) ... Unpacking replacement libssl1.0.0:i386 ... Setting up libssl1.0.0:i386 (1.0.1e-2+deb7u6) ... Checking for services that may need to be restarted...done. Checking init scripts... Restarting services possibly affected by the upgrade: [ ok ] Restarting OpenBSD Secure Shell server: sshd. [ ok ] Stopping NTP server: ntpd. [ ok ] Starting NTP server: ntpd. [ ok ] Stopping daemon monitor: monit. [ ok ] Starting daemon monitor: monit. Services restarted successfully. I tried disabling the $post script, but apparently there is no way to do this in Debian. Is it possible for someone on the thread to test it out. I can get back to this tomorrow. -abhi
RE: OpenSSL vunerability (bleedheart)
Courtesy Chiradeep - CPVM uses JSSE so that should not be affected - VR is not affected since it does not offer any HTTPS/TLS service. The RA VPN and S2S VPN use the OpenSSL lib only for crypto and not for any transport - The only vulnerable service is the volume upload service and template copy. The latter is between 2 trusted IPs - Also this should only affect SSVM template from 4.2 onwards as only wheezy is affected Thanks Animesh -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Wednesday, April 09, 2014 11:07 AM To: dev@cloudstack.apache.org Subject: Re: OpenSSL vunerability (bleedheart) I want to address a few things here directly (I think these are covered in the blog post, if not ping me) * Current SSVM from 4.3 is not good enough. * Yes, each SystemVM runs software that needs OpenSSL. For the curious, see lsof|grep -i ssl * I'm not sure if the current SystemVM template on Jenkins is secure, we're testing that currently and will update once confirmed. * Assume if you see us releasing a blog post about a security issue, there's a security issue (QED HTH HAND) * Realhostip uses SSL, but not on the SystemVMs. If you're using realhostIP, it doesn't matter what version of OSSL you use, you're still insecure. Horse: beaten. * Chiradeep's correct, 4.1 and older are not vulnerable. Post updated again. I think that covers the questions...running around doing a few things but this is very high on our priority list. (snarky comments are meant to be funny not insulting/condescending) On Apr 9, 2014, at 10:19 AM, John Kinsella j...@stratosec.comailto:j...@stratosec.co wrote: To my knowledge, no code change is necessary just a rebuild. - j Please excuse typos - sent from mobile device. - Reply message - From: Rayees Namathponnan rayees.namathpon...@citrix.commailto:rayees.namathpon...@citrix.co m To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: OpenSSL vunerability (bleedheart) Date: Wed, Apr 9, 2014 10:13 AM Even if we get latest systemvm template from http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ . , it has openssl 1.0.1e-2+deb7u4 ? Is there any code change required to create system template with openssl 1.0.1e-2+deb7u6 ? Regards, Rayees -Original Message- From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com] Sent: Wednesday, April 09, 2014 5:15 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: OpenSSL vunerability (bleedheart) Latest System VMs have openssl 1.0.1e-2+deb7u4. We need to update openssl to get 1.0.1e-2+deb7u6. It will be great if some one can update openssl to 1.0.1e-2+deb7u6 and test OpenSSL HeartBleed Vulnerability. Right now I could not do it from our network. -Harikrishna On 09-Apr-2014, at 5:00 pm, Nux! n...@li.nux.romailto:n...@li.nux.ro wrote: On 09.04.2014 12:04, Abhinandan Prateek wrote: Latest jenkins build template have openSSL version 1.0.1e, the version that is compromised. Guys, do not panic. It is my understanding that in Debian, just like in RHEL, major versions will not change, i.e. Debian GNU/Linux 7.0 will EOL with openssl 1.0.1e, but they will backport stuff. After I did an apt-get update apt-get install openssl I got package version 1.0.1e-2+deb7u6 (dpkg -l|grep openssl) and this package is ok according to the changelog: aptitude changelog openssl says: openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high * Non-maintainer upload by the Security Team. * Enable checking for services that may need to be restarted * Update list of services to possibly restart -- Salvatore Bonaccorso car...@debian.orgmailto:car...@debian.org Tue, 08 Apr 2014 10:44:53 +0200 openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high * Non-maintainer upload by the Security Team. * Add CVE-2014-0160.patch patch. CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure. A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. -- Salvatore Bonaccorso car...@debian.orgmailto:car...@debian.org Mon, 07 Apr 2014 22:26:55 +0200 In conclusion, if System VMs have openssl 1.0.1e-2+deb7u5 or higher, then they are OK. Can anyone confirm they have 1.0.1e-2+deb7u5+ ? Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.rohttp://www.nux.ro Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
RE: [ACS4.3] Schedule reminder : 10 days to code freeze
I sure don't want to start again on 4.3. I survived 9 RCs already and it is out . -Original Message- From: Anthony Xu [mailto:xuefei...@citrix.com] Sent: Tuesday, March 25, 2014 11:08 AM To: 'dev@cloudstack.apache.org' Subject: RE: [ACS4.3] Schedule reminder : 10 days to code freeze 4.3/4.4? -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, November 26, 2013 9:20 PM To: dev@cloudstack.apache.org Subject: [ACS4.3] Schedule reminder : 10 days to code freeze Folks We are now 10 days from ACS 4.3 code freeze and our bug fix activity is very slow. If you have any issues assigned to you please try to resolve them ASAP and help close the unassigned issues. For detailed report visit the release dashboard [1] [1] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=1232162 5 Thanks Animesh
RE: release estimations for ACS 4.3
Release VOTE passed we are working on formal release announcement and it should be out soon Animesh -Original Message- From: Andrei Mikhailovsky [mailto:and...@arhont.com] Sent: Monday, March 24, 2014 7:26 AM To: dev@cloudstack.apache.org Subject: release estimations for ACS 4.3 Hello guys, Any idea when 4.3 will be out? Thanks Andrei
Re: [VOTE] [RESULTS] Apache CloudStack 4.3.0 (ninth round)
Sure lets track them for 4.3.1 and 4.4 Thanks Animesh On Mar 22, 2014, at 3:56 PM, ilya musayev ilya.mailing.li...@gmail.com wrote: I did find some issue - but relatively minor and nothing that could not have been fixed via UI. I will open JIRA to address the issues. In the nutshell, i noticed some UI inconsistency and the way some pages are presented - this is minor but the issue was seen in both latest Firefox and Chrome on OSX. Another issue was related to VMware, if you define vSwitch0 under physical network labels for MGMT, Public, Guest and Storage, ACS 4.3 looks for a vSwitch named vSwitch0vSwitch0. There is vSwitch0 label that is defined as default in case nothing was supplied for vSwitch0 name - which is vSpheres default vSwitch, however, i decided to define it anyway to see what happens - surely enough it broke. It appears instead of replacing my value defined in UI, ACS appends my value + default value. As a result, vSwitch0vSwitch0 - is invalid vSwitch in VMware, and attempts to deploy SysVMs fail. I havent tried defining other vSwitches because all my test hypervisors only leverage vSwitch0. If i undefine the vSwitch0 label, ACS then picks up proper default vSwitch0. On 3/22/14, 3:39 AM, Wilder Rodrigues wrote: Great news! Have a nice weekend, guys and gals! Cheers, Wilder Sent from my iPhone On 21 Mar 2014, at 20:08, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: The vote has *passed* with the following results (binding PMC votes indicated with a * next to their name: +1 : Animesh*, Edison*, Ilya*, Amogh, Wilder +0 : Daan * -1 : Tanner (The issue CLOUDSTACK-6266 could not be reproduced ) I'm going to proceed with moving the release into the distribution repo now and other release tasks. Thanks Animesh -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, March 18, 2014 12:06 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (ninth round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro cedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh
RE: [VOTE] Apache CloudStack 4.3.0 (ninth round)
+ 1 (binding) verified the release artifacts and tested with devcloud -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, March 18, 2014 12:06 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (ninth round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro cedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh
RE: [VOTE] Apache CloudStack 4.3.0 (ninth round)
It should work and has been tested, adding Amogh and Sadhu -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, March 20, 2014 10:19 AM To: dev Subject: Re: [VOTE] Apache CloudStack 4.3.0 (ninth round) Thanks Ove, It looks like the info I want. I will give it a try. (almost hitting myself) On Thu, Mar 20, 2014 at 6:05 PM, Ove Ewerlid ove.ewer...@oracle.com wrote: On 03/20/2014 05:58 PM, Daan Hoogland wrote: again I am seriously considering -1 (binding) and (sigh) and. Is there any doc I missed on getting the console proxy working in 4.3, that will make me hit me on the head and retract this thread? A pointer to this will fit nicely in the 4.3 release notes; https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+cha nges#RealhostIPchanges-Upgrade just checked, did not fine any note about this. There have been email threads where this link has been noted on the dev list. /Ove On Tue, Mar 18, 2014 at 9:38 PM, Wilder Rodrigues wrodrig...@schubergphilis.com wrote: Hi there Ilya, Could you please provide which tests cases you have covered? I would like to add them to my tests round as well. Currently I'm testing multiple zones, networks, instances, ACLs, Port Forwarding and will add security groups. If you have more points, I would be glad to test them as well. Thanks in advance. Cheers, Wilder -Original Message- From: ilya musayev [mailto:ilya.mailing.li...@gmail.com] Sent: Tuesday, March 18, 2014 9:11 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (ninth round) +1 binding On 3/18/14, 3:05 PM, Animesh Chaturvedi wrote: Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog ;h=refs/heads/4.3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test +procedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh -- Ove Everlid System Administrator / Architect / SDN- Automation- Linux-hacker Mobile: +46706662363 (dedicated work mobile) Country: Sweden, timezone; Middle Europan Time (MET or GMT+1) -- Daan
RE: [VOTE] Apache CloudStack 4.3.0 (ninth round)
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, March 20, 2014 10:25 AM To: dev Cc: Amogh Vasekar; Suresh Sadhu Subject: Re: [VOTE] Apache CloudStack 4.3.0 (ninth round) On Thu, Mar 20, 2014 at 6:21 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: should work You mean 'should work after default installation, Animesh? consoleproxy.url.domain is empty. [Animesh] Yes and that will default as http thanks, -- Daan
RE: [VOTE] Apache CloudStack 4.3.0 (ninth round)
That's weird but I do not see the issue in my setup. Copying jessicaW -Original Message- From: Tanner Danzey [mailto:arkan...@gmail.com] Sent: Thursday, March 20, 2014 4:40 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (ninth round) -1 see https://issues.apache.org/jira/browse/CLOUDSTACK-6266 (If it is something easily fixed I will happily rescind my -1) On Thu, Mar 20, 2014 at 4:32 PM, Edison Su edison...@citrix.com wrote: +1(binding) After fixed the serious bugs in security group in the last round. -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, March 18, 2014 12:06 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (ninth round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+ pr ocedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh -- *Tanner Danzey* Systems Engineer Northstar Technology Group arkan...@gmail.com / tanner.dan...@northstar-tg.com (701) 237-9096 x7122
RE: [VOTE] Apache CloudStack 4.3.0 (ninth round)
Can you clear up browser cache and try again? -Original Message- From: Animesh Chaturvedi Sent: Thursday, March 20, 2014 4:54 PM To: dev@cloudstack.apache.org Cc: Jessica Wang Subject: RE: [VOTE] Apache CloudStack 4.3.0 (ninth round) That's weird but I do not see the issue in my setup. Copying jessicaW -Original Message- From: Tanner Danzey [mailto:arkan...@gmail.com] Sent: Thursday, March 20, 2014 4:40 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (ninth round) -1 see https://issues.apache.org/jira/browse/CLOUDSTACK-6266 (If it is something easily fixed I will happily rescind my -1) On Thu, Mar 20, 2014 at 4:32 PM, Edison Su edison...@citrix.com wrote: +1(binding) After fixed the serious bugs in security group in the +last round. -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, March 18, 2014 12:06 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (ninth round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4 .3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+tes t+ pr ocedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh -- *Tanner Danzey* Systems Engineer Northstar Technology Group arkan...@gmail.com / tanner.dan...@northstar-tg.com (701) 237-9096 x7122
RE: Release cadence
-Original Message- From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] Sent: Wednesday, March 19, 2014 4:46 AM To: dev Subject: Re: Release cadence The primary problem I feel is that we dont plan our releases.(I am fairly new here and I may be wrong) The role of the release manager starts only during the RC creation phase asking for votes(again I maybe wrong). [Animesh] Rajani releases are actually planned well ahead. Please check out the Release page for 4.3 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.3+Release The planning is straight forward with our time baaed releases I feel it should start much earlier. Everyone who is actively involved should have a clear idea on what we are going to release next. We do this to an extent by sending proposals etc. but we really dont do planning and the big picture is missing. [Animesh] The plan is published and socialized check out how it was done for 4.3 http://markmail.org/message/7hnkyphpz5hkk6rm I think with 4.3 multiple RCs, 4.4 got rushed in and we did not see the plan and the feature freeze came in. Daan/Hugo are yet to setup the plan for 4.4 I think the RM should facilitate planning of the release and in the process take feedback from the committers and users who are going to work on the release. A single view of the current release status also would help immensely. I like the way brackets.io does the release management through trello boards[1]. Probably we could explore such options. It facilities voting on features, gives a quick view of whats getting in the release which would help QA/anyone interested in testing to plan the testing early on instead of waiting for RC. I am for for short release cycles. Release early, release often It shows project activity and builds developer confidence as long as we do quality releases :) [1] https://trello.com/b/LCDud1Nd/brackets ~Rajani On 17-Mar-2014, at 10:22 pm, John Kinsella j...@stratosec.co wrote: I am in agreement with my radical CloudStack brother. On Mar 13, 2014, at 9:42 AM, David Nalley da...@gnsa.us wrote: The RC7 vote thread contained a lot of discussion around release cadence, and I figured I'd move that to a thread that has a better subject so there is better visibility to list participants who don't read every thread. When I look at things schedule wise, I see our aims and our reality. We have a relatively short development window (in the schedule) and we have almost 50% of our time in the schedule allocated to testing. (over two months). However, it seems that a lot of testing - or at least a lot of testing for what became blockers to the release didn't appear to happen until RCs were kicked out - and that's where our schedule has fallen apart for multiple releases. The automated tests we have were clean when we issued RCs, so we clearly don't have the depth needed from an automated standpoint. Two problems, one cultural and one technical. The technical problem is that our automated test suite isn't deep enough to give us a high level of confidence that we should release. The cultural problem is that many of us wait until the release period of the schedule to test. What does that have to do with release cadence? Well inherently not much; but let me describe my concerns. As a project; the schedule is meaningless if we don't follow it; and effectively the release date is held hostage. Personally, I do want as few bugs as possible, but it's a balancing act where people doubt our ability if we aren't able to ship. I don't think it matters if we move to 6 month cycles, if this behavior continues, we'd miss the 6 month date as well and push to 8 or 9 months. See my radical proposition at the bottom for an idea on dealing with this. I also find myself agreeing with Daan on the additional complexity. Increasing the window for release inherently increases the window for feature development. As soon as we branch a release, master is open for feature development again. This means a potential for greater change at each release. Change is a risk to quality; or at least an unknown that we again have to test. The greater that quantity of change, the greater the potential threat to quality. Radical proposition: Because we have two problems, of different nature, we are in a difficult situation. This is a possible solution, and I'd appreciate you reading and considering it. Feedback is welcome. I propose that after we enter the RC stage that we not entertain any bugs as blockers that don't have automated test cases associated with them. This means that you are still welcome to do manual testing of your pet feature and the things that are important to you; during the testing window (or anytime really). However, if the automation suite isn't also failing then we consider the release as high enough quality to
RE: [ACS 4.4] RE: 4.4 Feature Freeze
Daan/ Hugo We need to update the wiki release page for 4.4 and also setup the JIRA dashboard similar to what I did for 4.2 and 4.3. Let me know if you have questions on how it was done for 4.3 Thanks Animesh -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: Wednesday, March 19, 2014 5:46 PM To: dev@cloudstack.apache.org Cc: Hugo Trippaers (htrippa...@schubergphilis.com) Subject: [ACS 4.4] RE: 4.4 Feature Freeze Hi, I have copied one of the project pages from prior release for ACS 4.4[1]. Will be posting some of the QA artifacts in QA plan section. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=3962319 2 Thanks /sudha -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: Tuesday, March 11, 2014 2:18 PM To: dev@cloudstack.apache.org Subject: RE: 4.4 Feature Freeze Hugo, Is it possible to setup Project page [1] on cwiki ? I am interested to post some of the QA artifacts there related to ACS 4.4. I can also copy one from prior releases if that is okay. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progr ess Thanks /Sudha -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Tuesday, March 11, 2014 8:28 AM To: dev@cloudstack.apache.org Subject: Re: 4.4 Feature Freeze Hey guys, I didn't go and tally all the +1s and -1s for the shift of the feature freeze, but with so many reactions i feel sticking to the schedule is the only way to go. We should only change dates if there is a consensus and there clearly is none at the moment. Let's take this discussion to the 4.5 release if we need to or focus on doing a high quality release for 4.4 so we can focus on features again in 4.4 This means that the feature freeze would be this friday and i intend to cut the 4.4 branch around 14:00 CET As we have a 72 hour window for MERGE requests, please make sure they are in today (if the feature is ready). Cheers, Hugo
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Monday, March 17, 2014 3:57 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 17.03.2014 22:39, Animesh Chaturvedi wrote: Edison Thanks for taking care of this issue. Nux can you try with this fix and I will go off building RC Animesh, First thing tomorrow morning (gmt). [Animesh] Thanks I rebuilt the RC but have not published it yet. The link and details are same as RC8 except for the commitId 0810029f274878eca8fd74b44ab1117054e929a5 Here is the link anyway https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Tuesday, March 18, 2014 7:04 AM To: Animesh Chaturvedi Cc: dev@cloudstack.apache.org; Edison Su Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 17.03.2014 22:39, Animesh Chaturvedi wrote: Edison Thanks for taking care of this issue. Nux can you try with this fix and I will go off building RC Animesh, can you also pull in the patches Jayapal wrote to fix the ipset issue? https://issues.apache.org/jira/browse/CLOUDSTACK-6240 [Animesh] Looks like that will need more work and given that there is a workaround we can track this for maintenance release Thanks! Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
[VOTE] Apache CloudStack 4.3.0 (ninth round)
Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 0810029f274878eca8fd74b44ab1117054e929a5 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours (Friday 3/21 12:05 PM PST) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh
RE: 32 vs 64 bit systemvm on 43 and secondary NFS storage used / capacity Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message-
From: Ove Ewerlid [mailto:ove.ewer...@oracle.com]
Sent: Monday, March 17, 2014 9:09 AM
To: dev@cloudstack.apache.org
Subject: 32 vs 64 bit systemvm on 43 and secondary NFS storage used /
capacity Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)
Has anyone else seen below behavior with 4.3.0 RC 8?
- with 32 bit system VM, the secondary storage is reported as 0/0 (this is
at
the agent level, not a GUI or manager issue)
- with 64 bit system VM, the secondary storage is reported OK.
[Animesh] We have defaulted to 64 bit template for 4.3
Environment;
- ACS43RC8, installed from RPM on OEL65 (64bit) built on OEL65 (64bit)
using centos63/package.sh
- Secondary storage on NFS
- 64 bit systemvm;
systemvm64template-2014-03-12-master-kvm.qcow2.bz2
32 bit systemvm;
systemvmtemplate-2014-03-12-master-kvm.qcow2.bz2
picked from here;
http://jenkins.buildacloud.org/view/4.3/
When 32-bit systemvm is used with 4.2.1 on the very same environment
built the same way. The secondary storage is reported OK.
With increased debug level on secondary storage systemvm the following is
logged from the SSVM agent, example from 64-bit systemvm; ...
[{com.cloud.agent.api.GetStorageStatsAnswer:{used:481910849536,capa
city:3298534883328,result:true,contextMap:{},wait:0}}]
...
With a 32-bit systemvm, ACS43 GetStorageStatsAnswer reports used=0 and
capacity=0.
/Ove
On 03/13/2014 01:26 AM, Animesh Chaturvedi wrote:
Hi All,
I've created a 4.3.0 release, with the following artifacts up for a
vote:
Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
refs/heads/4.3
Commit: 6a6ec648099553a42f830dcd566eab2452428908
List of changes:
New Features in 4.3:
https://issues.apache.org/jira/issues/?filter=12325248
Improvement in 4.3:
https://issues.apache.org/jira/issues/?filter=12325249
Issues fixed in 4.3
https://issues.apache.org/jira/issues/?filter=12326161
Known Issues in 4.3:
https://issues.apache.org/jira/issues/?filter=12326162
Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/
PGP release keys (signed using 94BE0D7C):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS
Testing instructions are here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
ocedure
Vote will be open for 72 hours (Monday evening PST 5:30 PM)
For sanity in tallying the vote, can PMC members please be sure to indicate
(binding) with their vote?
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Thanks
Animesh
--
Ove Everlid
System Administrator / Architect / SDN- Automation- Linux-hacker
Mobile: +46706662363 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Monday, March 17, 2014 11:26 AM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (eighth round) Before we go to 9th round, let's get https://issues.apache.org/jira/browse/CLOUDSTACK-6156 resolved. [Animesh] I had responded earlier we do not see the issue with Jenkins build so if someone needs they can get it from the Jenkins, I don't consider it blocker and nobody seems to pick it up. We can track it for maintenance release on 4.3 I'm pretty busy this week, but will see if I can come up with. Just tried doing a clean awsapi build on a clean AWS instance again and it still fails. On Mar 12, 2014, at 5:26 PM, Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com wrote: Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 6a6ec648099553a42f830dcd566eab2452428908 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro cedure Vote will be open for 72 hours (Monday evening PST 5:30 PM) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Monday, March 17, 2014 2:48 PM To: dev@cloudstack.apache.org Cc: Likitha Shetty; Prachi Damle Subject: Re: [VOTE] Apache CloudStack 4.3.0 (eighth round) Thanks Sebastien. I had been intending to mail previous committers on the subdir. Prachi/Likitha - any comments on https://reviews.apache.org/r/18392/ would be appreciated. [Animesh] Removing rampart dependency will need testing AWSAPI again, I am inclined to track this for 4.3 maintenance or 4.4 release On Mar 17, 2014, at 12:54 PM, Sebastien Goasguen run...@gmail.commailto:run...@gmail.com wrote: John, I am copying Likitha and Prachi who worked on awsapi, maybe they can help -sebastien On Mar 17, 2014, at 2:25 PM, John Kinsella j...@stratosec.comailto:j...@stratosec.co wrote: Before we go to 9th round, let's get https://issues.apache.org/jira/browse/CLOUDSTACK-6156 resolved. I'm pretty busy this week, but will see if I can come up with. Just tried doing a clean awsapi build on a clean AWS instance again and it still fails. On Mar 12, 2014, at 5:26 PM, Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.comm ailto:animesh.chaturv...@citrix.com wrote: Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 6a6ec648099553a42f830dcd566eab2452428908 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro cedure Vote will be open for 72 hours (Monday evening PST 5:30 PM) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella Stratosechttp://stratosec.co/ - Compliance as a Service o: 415.315.9385 @johnlkinsellahttp://twitter.com/johnlkinsella
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
Edison Thanks for taking care of this issue. Nux can you try with this fix and I will go off building RC -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Monday, March 17, 2014 2:52 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) I added another commit: d4fdc184fe9c6717d2ed4e4fe4c39d9759a90608, which will fix a race condition during security group programming. It's sort of a timing issue, the behavior will look like this: 1. add a security group rule, but the rule is not send to hypervisor 2. add a new rule, only the 1st rule added in the above step is send to hypervisor host, 3. and so on, the rules in hypervisor host is always lagging behind the rules in DB. CLOUDSTACK-6245 has more info about this issue. -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Saturday, March 15, 2014 2:27 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 15.03.2014 21:18, Sangeetha Hariharan wrote: In this case , is it possible that when you tried to ping the instance , the instance had not booted completely? No, I made sure it's fully booted first. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
[CANCELLED] [VOTE] Apache CloudStack 4.3.0 (eighth round)
Cancelling this VOTE too because of Nux's finding of KVM SecurityGroup is broken. Thanks Animesh From: Animesh Chaturvedi Sent: Wednesday, March 12, 2014 5:27 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (eighth round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: 6a6ec648099553a42f830dcd566eab2452428908 List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours (Monday evening PST 5:30 PM) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks Animesh
RE: Differences between 4.3 and 4.3-forward
-Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Friday, March 14, 2014 7:43 AM To: dev@cloudstack.apache.org Subject: Re: Differences between 4.3 and 4.3-forward Yes, and we definitely cannot just take all of 4.3.1 and put it in 4.3 as many of those changes are intended for 4.3.1 and not 4.3. [Animesh] Yes that is correct. I was pulling in commits that I was asked to cherry-pick from 4.3-forward and the one that I thought were important. There were some that I had not picked up and had followed up with few folks like Marcus in case they need to be pulled in. We cannot pull in 4.3-forward into 4.3. 4.3-forward branch will be merged into 4.3 after 4.3 is released On Fri, Mar 14, 2014 at 8:40 AM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Yes - 4.3-forward is unstable branch and should be merged while 4.3 is going through RC. It is meant for maintenance release. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Friday, March 14, 2014 7:36 AM To: dev@cloudstack.apache.org Subject: Re: Differences between 4.3 and 4.3-forward Right, I think it's dangerous to sync 4.3.1 to 4.3 because developers might have changes in 4.3.1 that are not yet in master. This is not my situation personally, but I imagine some devs might be in this state. On Fri, Mar 14, 2014 at 8:18 AM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Yes that is my understanding that all of these would go in to next maintenance that is why they are staged in forward branch. -Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: Friday, March 14, 2014 1:38 AM To: dev@cloudstack.apache.org Subject: RE: Differences between 4.3 and 4.3-forward Will these automatically go into 4.3.1, do we know if they've gone into master as well? Otherwise does this mean we have a load of bug fixes which we're not putting into 4.3.0 which could potentially become orphaned in the 4.3-forward branch? (this query may be just my ignorance regarding ACS branching) Regards, Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: 12 March 2014 08:29 To: dev@cloudstack.apache.org Subject: Differences between 4.3 and 4.3-forward Hey, There is a sizable number of differences between the two branch. Maybe it's time to ditch 4.3-forward and recreate it based on current 4.3? Cheers, Hugo Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat 4.3-forward 4.3 api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCert ToLoadBalancerCmd.java |3 +- api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCer t FromLoadBalancerCmd.java |2 +- awsapi/pom.xml |2 +- client/pom.xml | 20 ++- client/tomcatconf/catalina.properties.in |2 +- debian/changelog |7 +- developer/pom.xml |1 - engine/components- api/src/com/cloud/template/TemplateManager.java |9 +- engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java | 36 + engine/orchestration/src/org/apache/cloudstack/engine/orchestration/Vo lumeOrchestrator.java | 10 +- engine/schema/resources/META-INF/cloudstack/core/spring-engine- schema- core-daos-context.xml |2 +- engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDa taStoreDao.java |2 - engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDa taStoreDaoImpl.java | 48 +- engine/storage/integration-test/pom.xml |5 - engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStorag ePoolAllocator.java |8 +- framework/db/pom.xml |5 - framework/db/src/com/cloud/utils/db/StaticStrategy.java | 130 plugins/database/mysql-ha/pom.xml | 28 plugins/database/mysql-ha/src/com/cloud/utils/db/StaticStrategy.java | 133
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Friday, March 14, 2014 12:37 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Friday, March 14, 2014 12:19 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 14.03.2014 19:14, Edison Su wrote: Hi Nux, Could you post security group log file on your 4.3 kvm host? The file is @/var/log/cloudstack/agent/security_group.log Thanks Edison, but the problem went away once I replaced that python script with https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/net wo rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0 898a264a5463b85c4cab3033f9c3161c5ef83f8 But the code is not for 4.3, right? I want to figure out, why 4.3 security group is broken. [Animesh] Yes I am curious too as there was no planned change for 4.3 and how it regressed? Do you still require the log file? Yes, it's better to find out why. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: cherrypick to 4.3
If I build another RC I will pick it up From: Alena Prokharchyk Sent: Friday, March 14, 2014 12:43 PM To: Animesh Chaturvedi Cc: dev@cloudstack.apache.org Subject: Re: cherrypick to 4.3 Animesh, one more commit for the same bug needs to be cherry-picked: 94817c1b4b89cfa69f2db50a7060dcb7d7c39dbb -alena. From: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com Date: Wednesday, March 5, 2014 at 4:49 PM To: Animesh Chaturvedi animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com Cc: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: cherrypick to 4.3 Animesh, can you please cherry-pick one more commit from 4.3-forward to 4.3? Its a one liner change, yet it fixes Critical bug for VPC d009c8c7b229a1bb02834f52d9cac17f46e33349 https://issues.apache.org/jira/browse/CLOUDSTACK-6205 VPC: when network is created in Setup state (with vlan specified), it never gets plugged to the VPC VR after restart Thanks, Alena.
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Friday, March 14, 2014 1:59 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
The following change will the be root cause:
-refs = execute(iptables -n -L + brfw + |grep + brfw + | cut
-d \( -f2
| awk '{print $1}').strip()
+refs = execute(iptables -n -L + brfw + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % brfw).strip()
In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
The code should be
+refs = execute(iptables -n -L + %s + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % (brfw,
+ brfw)).strip()
[Animesh] Edison thanks for finding the root cause. Looking at the commit
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=052bff15c6603877e7a0767993eb4675e9bd9ca8
It has been broken since July last year and we did not run into it. Nux thanks
for catching it. Commit message simply says Replaced multiple grep/awk/head
commands by one awk command and the effects is pretty bad. There is no bug id
associated with commit. Why did we have to change it?
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 1:13 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:36, Edison Su wrote:
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:14, Edison Su wrote:
Hi Nux,
Could you post security group log file on your 4.3 kvm host?
The file is @/var/log/cloudstack/agent/security_group.log
Thanks Edison, but the problem went away once I replaced that
python script with
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/
ne
two
rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
898a264a5463b85c4cab3033f9c3161c5ef83f8
But the code is not for 4.3, right?
I want to figure out, why 4.3 security group is broken.
I think this is the key difference:
-A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -o brbond0-540 -j DROP
-A FORWARD -i brbond0-540 -j DROP
It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
I'll try to rollback to old script and send you the logs.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
Sent: Friday, March 14, 2014 2:28 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Friday, March 14, 2014 1:59 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
The following change will the be root cause:
-refs = execute(iptables -n -L + brfw + |grep + brfw + |
cut -d \( -
f2
| awk '{print $1}').strip()
+refs = execute(iptables -n -L + brfw + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % brfw).strip()
In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
The code should be
+refs = execute(iptables -n -L + %s + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % (brfw,
+ brfw)).strip()
[Animesh] Edison thanks for finding the root cause. Looking at the commit
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=052bff15c6603877e7a
0767993eb4675e9bd9ca8
It has been broken since July last year and we did not run into it. Nux thanks
for catching it. Commit message simply says Replaced multiple
grep/awk/head commands by one awk command and the effects is pretty
bad. There is no bug id associated with commit. Why did we have to change
it?
[Animesh] Can someone add a test case for this issue?
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 1:13 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:36, Edison Su wrote:
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:14, Edison Su wrote:
Hi Nux,
Could you post security group log file on your 4.3 kvm host?
The file is @/var/log/cloudstack/agent/security_group.log
Thanks Edison, but the problem went away once I replaced that
python script with
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/v
m/
ne
two
rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
898a264a5463b85c4cab3033f9c3161c5ef83f8
But the code is not for 4.3, right?
I want to figure out, why 4.3 security group is broken.
I think this is the key difference:
-A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -o brbond0-540 -j DROP
-A FORWARD -i brbond0-540 -j DROP
It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
I'll try to rollback to old script and send you the logs.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Friday, March 14, 2014 2:57 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward
branch.
I do see the rule coming on the kvm host:
-A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 -A
FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 -A
FORWARD -o cloudbr0 -j DROP -A FORWARD -i cloudbr0 -j DROP
Animesh, could you cherry-pick it into 4.3?
[Animesh] Edison thanks for the fix. Can you also add tracking bug in JIRA for
this issue. Nux do you mind pulling in Edison's commit and confirm the fix?
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: Friday, March 14, 2014 1:59 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
The following change will the be root cause:
-refs = execute(iptables -n -L + brfw + |grep + brfw + |
cut -d \( -
f2
| awk '{print $1}').strip()
+refs = execute(iptables -n -L + brfw + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % brfw).strip()
In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
The code should be
+refs = execute(iptables -n -L + %s + | awk
+ '/%s(.*)references/ {gsub(/\(/, ) ;print $3}' % (brfw,
+ brfw)).strip()
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 1:13 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:36, Edison Su wrote:
-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
On 14.03.2014 19:14, Edison Su wrote:
Hi Nux,
Could you post security group log file on your 4.3 kvm host?
The file is @/var/log/cloudstack/agent/security_group.log
Thanks Edison, but the problem went away once I replaced that
python script with
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/v
m/
ne
two
rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
898a264a5463b85c4cab3033f9c3161c5ef83f8
But the code is not for 4.3, right?
I want to figure out, why 4.3 security group is broken.
I think this is the key difference:
-A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
BF-brbond0-540
-A FORWARD -o brbond0-540 -j DROP
-A FORWARD -i brbond0-540 -j DROP
It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
I'll try to rollback to old script and send you the logs.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Thursday, March 13, 2014 12:41 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 13.03.2014 18:58, Nux! wrote: On 13.03.2014 00:26, Animesh Chaturvedi wrote: Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: -1 In Adv SG zone assigning secondary IPs to a NIC doesn't update the ipset accordingly on the agent/hv; it requires stopping/starting the VM. It's not a tragedy, but this was not the case in 4.2.1. Haven't checked basic zone. Actually something is very wrong, the SG don't seem to do anything, I have 2 setups with SG and 4.3 RC8 and on both the SG are useless. Not only the ipsets are not updated live, but all the traffic is accepted by default! Can anyone with Adv SG zone test? I'm on 4.3 rc8 + CentOS 6.5 HV. I will do more testing tomorrow. [Animesh] Did you see this with prior RC too? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
-Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Thursday, March 13, 2014 1:25 PM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round) -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Thursday, March 13, 2014 12:41 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (eighth round) On 13.03.2014 18:58, Nux! wrote: On 13.03.2014 00:26, Animesh Chaturvedi wrote: Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: -1 In Adv SG zone assigning secondary IPs to a NIC doesn't update the ipset accordingly on the agent/hv; it requires stopping/starting the VM. It's not a tragedy, but this was not the case in 4.2.1. Haven't checked basic zone. Actually something is very wrong, the SG don't seem to do anything, I have 2 setups with SG and 4.3 RC8 and on both the SG are useless. Not only the ipsets are not updated live, but all the traffic is accepted by default! Can anyone with Adv SG zone test? I'm on 4.3 rc8 + CentOS 6.5 HV. I will do more testing tomorrow. [Animesh] Did you see this with prior RC too? [Animesh] Nux, security group support for advanced zone is limited and that too was developed in 4.2. I don’t think any changes have been made to that support since then. Can you call out what specific issue are you seeing? Most likely it is pre-existing issue or not supported. The functional spec from 4.2 is at [1] and I don’t know if all that is called out is implemented or not, adding Anthony and Chiradeep to the thread for further comments [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+based+on+Security+Groups+in+Advance+zone -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: 4.4 Feature Freeze
Hugo Folks in USA will still have their day shining on 3/14. Can you cut it after the day in USA is over in PST time Animesh -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Tuesday, March 11, 2014 8:28 AM To: dev@cloudstack.apache.org Subject: Re: 4.4 Feature Freeze Hey guys, I didn't go and tally all the +1s and -1s for the shift of the feature freeze, but with so many reactions i feel sticking to the schedule is the only way to go. We should only change dates if there is a consensus and there clearly is none at the moment. Let's take this discussion to the 4.5 release if we need to or focus on doing a high quality release for 4.4 so we can focus on features again in 4.4 This means that the feature freeze would be this friday and i intend to cut the 4.4 branch around 14:00 CET As we have a 72 hour window for MERGE requests, please make sure they are in today (if the feature is ready). Cheers, Hugo
RE: [VOTE] Apache CloudStack 4.3.0 (seventh round)
Well we chose to keep the feature freeze while we had 4.3 still in progress. I don't think we want to hold off 4.3 because of 4.4. It needs to go out Animesh From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Wednesday, March 12, 2014 10:25 AM To: dev@cloudstack.apache.org Cc: Hugo Trippaers; Animesh Chaturvedi Subject: Re: [VOTE] Apache CloudStack 4.3.0 (seventh round) I hate to point this out as I know we've been struggling to get 4.3 out the door, but this week is probably not a great week to count votes for 4.3 as it is the last week before 4.4 Feature Freeze. On Wed, Mar 12, 2014 at 11:09 AM, Wilder Rodrigues wrodrig...@schubergphilis.commailto:wrodrig...@schubergphilis.com wrote: Hi guys and gals, Based on the findings after my first round of tests, I give a +1 to the 4.3 RC Please, find below what I have tested so far: * Environment - Management Server: Debian 7 VM under VirtualBox - DevCloud: XenServer 6.2 - MySQL: running on the DevCloud - System VM: Latest from http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/ * Initial start-up - Everything seems to work fine * Zone - DNS1: 8.8.8.8 - DNS2: 8.8.4.4 - Hypervisor: XenServer - Guest CIDR: 10.1.2.0/24http://10.1.2.0/24 - Local Storage enabled: true * Public Traffic - 10.1.1.1 / 255.255.255.0 / 10.1.1.2 / 10.1.1.100 * POD - 10.1.1.1 / 255.255.255.0 / 10.1.1.101 / 10.1.1.200 * VLAN - 101 - 109 * Host - Host Name: 178.237.34.120 - Username: root - Password: blah * Secondary Storage - Provider: NFS - Name: sec01 - Server: 10.1.1.114 - Path: /opt/storage/secondary ::: ALL GREEN UP TO NOW ::: * Create Instance - Featured: Tiny Linux - Compute Offering: Tiny Offering - Disk Offering: None - Instance name: cs43-01 * NIC Information - IP Address: 10.1.2.186 - Gateway: 10.1.2.1 - Netmask: 255.255.255.0 * Create Network - Name: devcloud-net01 - Type: Isolated - CIDR: 10.1.2.0/24http://10.1.2.0/24 - Public IP: 10.1.1.4 [Source NAT] - Egress Rules: 0.0.0.0/0http://0.0.0.0/0 - All - Network Offering: Offering for Isolated networks with Source Nat service enabled * Create ACLs - 10.1.0.0/16http://10.1.0.0/16 - TCP - 22 - 22 - 10.1.0.0/16http://10.1.0.0/16 - TCP - 443 - 443 * Create Port Forwarding - 22:22 - 22:22 - instance cs43-01 [10.1.2.186] - 443:443 - 443:443 - instance cs43-01 [10.1.2.186] * SSH into the new instance via the Public IP: [root@devcloud-wil01 ~]# ssh root@10.1.1.4mailto:root@10.1.1.4 The authenticity of host '10.1.1.4 (10.1.1.4)' can't be established. RSA key fingerprint is 02:43:6c:24:c5:79:b6:e2:c8:b7:e8:3c:8d:13:37:91. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.1.1.4' (RSA) to the list of known hosts. root@10.1.1.4mailto:root@10.1.1.4's password: % % % ls ssh-host-dss-key.pub ssh-host-rsa-key.pub % cd / % ls bin bootdev etc homelib lost+found mnt procrootsbinsys tmp usr var % With kind regards, Wilder -Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.commailto:paul.an...@shapeblue.com] Sent: Wednesday, March 12, 2014 12:45 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org; Hugo Trippaers Cc: Animesh Chaturvedi Subject: RE: [VOTE] Apache CloudStack 4.3.0 (seventh round) Yes, I can build now. :-) Regards Paul Angus Cloud Architect S: +44 20 3603 0540tel:%2B44%2020%203603%200540 | M: +447711418784tel:%2B447711418784 | T: CloudyAngus paul.an...@shapeblue.commailto:paul.an...@shapeblue.com -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.commailto:damoder.re...@citrix.com] Sent: 12 March 2014 10:49 To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org; Hugo Trippaers Cc: Animesh Chaturvedi Subject: RE: [VOTE] Apache CloudStack 4.3.0 (seventh round) HI Paul, After you pull Hugo changes are you able to build now? Thanks Regards Damodar/ -Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.commailto:paul.an...@shapeblue.com] Sent: Wednesday, March 12, 2014 2:04 PM To: Hugo Trippaers Cc: Animesh Chaturvedi; dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (seventh round) Yes that's correct. I'm building noredist Regards, Paul Angus S: +44 20 3603 0540tel:%2B44%2020%203603%200540tel:+44%2020%203603%200540 | M: +447711418784tel:%2B447711418784tel:+447711418784tel:%2B447711418784 T: @CloudyAngus paul.an...@shapeblue.commailto:paul.an...@shapeblue.commailto:paul.an...@shapeblue.commailto:paul.an...@shapeblue.com Original message From: Hugo Trippaers Date:12/03/2014 07:32 (GMT+00:00) To: Paul Angus Cc: Animesh Chaturvedi ,dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [VOTE] Apache CloudStack 4.3.0 (seventh round) Hey Paul, Just to be clear, this problem
RE: [4.3] CLOUDSTACK cidr list length
I see your this commit + one another f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8 for CLOUDSTACK-6232 That is it right so two commits. There is one more I just saw that is mostly checkstyle fixes 0379dbb489b2502b8cf89583afd1a1f3baec93a3 which is trivial -Original Message- From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] Sent: Wednesday, March 12, 2014 9:08 AM To: dev@cloudstack.apache.org Subject: [4.3] CLOUDSTACK cidr list length Animesh, This is one of two production issues that we have. I will be sending you the other one shortly. I was planning to wait till 4.3.1 but that one is a blocker for us. This one is 454cac448d83b973d8cd337cf214b17e31828b93 Thanks, Daan
RE: [4.3] CLOUDSTACK cidr list length
Ok so does the last commit edf97ac86c94741ae8964b640bdfc0234929c1e4 is the final one and addresses Alena's concern. I want to rebuild RC if we are good to go -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, March 12, 2014 11:26 AM To: dev Subject: Re: [4.3] CLOUDSTACK cidr list length H Animesh, tyhe other one is for 6232 and I cherrypicked it without recompile, hence the tabs to spaces commit. I am still in discussion with Alena about it. She thinks it is incomplete. It is functional for us, but she might be right anyway. I don't think it will compile with the trivial one but f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8 is the blocker (regression) On Wed, Mar 12, 2014 at 7:16 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I see your this commit + one another f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8 for CLOUDSTACK-6232 That is it right so two commits. There is one more I just saw that is mostly checkstyle fixes 0379dbb489b2502b8cf89583afd1a1f3baec93a3 which is trivial -Original Message- From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] Sent: Wednesday, March 12, 2014 9:08 AM To: dev@cloudstack.apache.org Subject: [4.3] CLOUDSTACK cidr list length Animesh, This is one of two production issues that we have. I will be sending you the other one shortly. I was planning to wait till 4.3.1 but that one is a blocker for us. This one is 454cac448d83b973d8cd337cf214b17e31828b93 Thanks, Daan -- Daan
[CANCELLED] [VOTE] Apache CloudStack 4.3.0 (seventh round)
Cancelling this VOTE because of issues called out by Daan and Paul and off to building another RC From: Animesh Chaturvedi Sent: Monday, March 10, 2014 8:00 PM To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (seventh round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: ec4db7bbff60f0be96e39f51c0f17b12e0de440c List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 36 hours (Thursday evening PST 8:00 PM) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
RE: [VOTE] Apache CloudStack 4.3.0 (seventh round)
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, March 12, 2014 2:52 PM To: dev Cc: Hugo Trippaers; Animesh Chaturvedi Subject: Re: [VOTE] Apache CloudStack 4.3.0 (seventh round) If we produce a new feature per week, why not? [Animesh] We take a week to go through one RC so let's be practical and be cognizant of our resources and technical debt. On Wed, Mar 12, 2014 at 10:34 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: There has to be some minimum boundary, though, right? Otherwise we might as well release every week. :) On Wed, Mar 12, 2014 at 3:10 PM, Daan Hoogland daan.hoogl...@gmail.comwrote: Steve, As I have suggested before, we shoud not lengthen releas periods but shorten them. I highly object to the idea of enlarging the window and the release. It will pnly make relasing more difficult. with n releases there are n*(n-1) potential conficts of the simlest kind and n*(n-1)(n-2) potential conflicts of a slightly mor complex kind... The higher n ... do the math. The more we postpone a feature freeze the higher n will get. And that is only talking of features. not about the simpler fixes that are added. postponing when we have difficulty releasing quality makes no sense. kind regards, Daan Hoogland On Wed, Mar 12, 2014 at 9:46 PM, Steve Wilson steve.wil...@citrix.com wrote: I think it was suggested multiple times that we push out the 4.4 freeze date because the 4.3 work has been lagging. I think this is just another indicator we need to evaluate our release cadence as a community. That being said, I don¹t think we want to hold 4.3 any further. This must be the best tested RC in the history of software at this point. Unless someone finds a new showstopper (that wasn¹t in the previous 6 builds!) then let¹s get this puppy out! :-) -Steve On 3/12/14, 10:25 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I hate to point this out as I know we've been struggling to get 4.3 out the door, but this week is probably not a great week to count votes for 4.3 as it is the last week before 4.4 Feature Freeze. On Wed, Mar 12, 2014 at 11:09 AM, Wilder Rodrigues wrodrig...@schubergphilis.com wrote: Hi guys and gals, Based on the findings after my first round of tests, I give a +1 to the 4.3 RC Please, find below what I have tested so far: * Environment - Management Server: Debian 7 VM under VirtualBox - DevCloud: XenServer 6.2 - MySQL: running on the DevCloud - System VM: Latest from http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-system vm/ * Initial start-up - Everything seems to work fine * Zone - DNS1: 8.8.8.8 - DNS2: 8.8.4.4 - Hypervisor: XenServer - Guest CIDR: 10.1.2.0/24 - Local Storage enabled: true * Public Traffic - 10.1.1.1 / 255.255.255.0 / 10.1.1.2 / 10.1.1.100 * POD - 10.1.1.1 / 255.255.255.0 / 10.1.1.101 / 10.1.1.200 * VLAN - 101 - 109 * Host - Host Name: 178.237.34.120 - Username: root - Password: blah * Secondary Storage - Provider: NFS - Name: sec01 - Server: 10.1.1.114 - Path: /opt/storage/secondary ::: ALL GREEN UP TO NOW ::: * Create Instance - Featured: Tiny Linux - Compute Offering: Tiny Offering - Disk Offering: None - Instance name: cs43-01 * NIC Information - IP Address: 10.1.2.186 - Gateway: 10.1.2.1 - Netmask: 255.255.255.0 * Create Network - Name: devcloud-net01 - Type: Isolated - CIDR: 10.1.2.0/24 - Public IP: 10.1.1.4 [Source NAT] - Egress Rules: 0.0.0.0/0 - All - Network Offering: Offering for Isolated networks with Source Nat service enabled * Create ACLs - 10.1.0.0/16 - TCP - 22 - 22 - 10.1.0.0/16 - TCP - 443 - 443 * Create Port Forwarding - 22:22 - 22:22 - instance cs43-01 [10.1.2.186] - 443:443 - 443:443 - instance cs43-01 [10.1.2.186] * SSH into the new instance via the Public IP: [root@devcloud-wil01 ~]# ssh root@10.1.1.4 The authenticity of host '10.1.1.4 (10.1.1.4)' can't be established. RSA key fingerprint is 02:43:6c:24:c5:79:b6:e2:c8:b7:e8:3c:8d:13:37:91. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.1.1.4' (RSA) to the list of known hosts. root@10.1.1.4's password: % % % ls ssh-host-dss-key.pub ssh-host-rsa-key.pub % cd / % ls bin bootdev etc homelib lost+found mnt procrootsbinsys tmp usr var % With kind regards, Wilder -Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: Wednesday, March 12, 2014 12:45 PM To: dev
RE: [4.3][CLOUDSTACK-6232]isolated network can no longer reserve ip range
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, March 12, 2014 11:45 AM To: dev; Animesh Chaturvedi Subject: [4.3][CLOUDSTACK-6232]isolated network can no longer reserve ip range Animesh, I really feel for you in your role as release manager. I don't think anybody ever had such a hard time. [Animesh] Its ok I took up the responsibility so have to go through the journey with you all again this one solves our isolated net problem f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8 and this one my bogus tabs 0379dbb489b2502b8cf89583afd1a1f3baec93a3 and this one should get the ip space expansion in for isolated nets edf97ac86c94741ae8964b640bdfc0234929c1e4 Do you drink, Animesh. I really want to buy you one and i think everybody in the community should -- Daan
RE: [WIKI] Release test procedure contains wrong version of Java Open JDK
Yes that is correct. 1.7 was changes in master / 4.4. I will revert the changes for 4.3 release test procedure -Original Message- From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] Sent: Wednesday, March 12, 2014 1:41 PM To: dev@cloudstack.apache.org Subject: Re: [WIKI] Release test procedure contains wrong version of Java Open JDK Isn't it still JDK 1.6 for 4.3 = the current release, for which the old page was actually correct? Thanks, Amogh On 3/12/14 2:32 AM, Wilder Rodrigues wrodrig...@schubergphilis.com wrote: Already got rights and page has been edited. Thanks, Daan! Cheers, Wilder -Original Message- From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] Sent: Wednesday, March 12, 2014 10:19 AM To: dev@cloudstack.apache.org Subject: [WIKI] Release test procedure contains wrong version of Java Open JDK Hi guys and gals, Could I get rights to the Apache Wiki page? In case that's not possible, could someone please edit the page and change the version of the Java JDK? It now says 1.6 instead of 1.7. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr o ced ure sudo aptitude install openjdk-6-jdk Thanks in advance Cheers, Wilder
RE: [WIKI] Release test procedure contains wrong version of Java Open JDK
The change has been reverted. -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Wednesday, March 12, 2014 7:32 PM To: dev@cloudstack.apache.org Subject: RE: [WIKI] Release test procedure contains wrong version of Java Open JDK Yes that is correct. 1.7 was changes in master / 4.4. I will revert the changes for 4.3 release test procedure -Original Message- From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] Sent: Wednesday, March 12, 2014 1:41 PM To: dev@cloudstack.apache.org Subject: Re: [WIKI] Release test procedure contains wrong version of Java Open JDK Isn't it still JDK 1.6 for 4.3 = the current release, for which the old page was actually correct? Thanks, Amogh On 3/12/14 2:32 AM, Wilder Rodrigues wrodrig...@schubergphilis.com wrote: Already got rights and page has been edited. Thanks, Daan! Cheers, Wilder -Original Message- From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] Sent: Wednesday, March 12, 2014 10:19 AM To: dev@cloudstack.apache.org Subject: [WIKI] Release test procedure contains wrong version of Java Open JDK Hi guys and gals, Could I get rights to the Apache Wiki page? In case that's not possible, could someone please edit the page and change the version of the Java JDK? It now says 1.6 instead of 1.7. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+p r o ced ure sudo aptitude install openjdk-6-jdk Thanks in advance Cheers, Wilder
RE: [VOTE] Apache CloudStack 4.3.0 (seventh round)
-Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: Tuesday, March 11, 2014 10:35 AM To: dev@cloudstack.apache.org Subject: RE: [VOTE] Apache CloudStack 4.3.0 (seventh round) Trying to build 4.3, the process bombs out for me at MySQL HA Strategy. And strangely it seems to be trying to build MySQL from Master (4.4.0- SNAPSHOT)? [Animesh] Ok this came in from Hugo's commit that I cherry-picked https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=472a387d2d828e21aff93a750ed3e178837a1879 from file plugins/database/mysql-ha/pom.xml This is a version issue which can be fixed but should not affect functioning. Lets hear from Hugo on this. The other errors are formatting issues caught by checkstyle plugin that can be ignored. The Jenkins build is successful. Ideas anyone? [INFO] Apache CloudStack Plugin - MySQL HA Strategy .. FAILURE [1.110s] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle- plugin:2.11:check (cloudstack-checkstyle) on project cloud-plugin-database- mysqlha: Failed during checkstyle execution: There are 6 checkstyle errors. - [Help 1] [INFO] [INFO] Building Apache CloudStack Plugin - MySQL HA Strategy 4.4.0- SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-plugin- database-mysqlha --- [INFO] Deleting /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql-ha/target (includes = [**/*], excludes = []) [INFO] Deleting /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql-ha (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-plugin-database-mysqlha --- [INFO] Starting audit... /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:54: Line has trailing spaces. /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:58: Line has trailing spaces. /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:60: Line has trailing spaces. /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:110: Line has trailing spaces. /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:120: Line has trailing spaces. /usr/local/4.3/cloudstack/dist/rpmbuild/BUILD/cloudstack- 4.3.0/plugins/database/mysql- ha/src/com/cloud/utils/db/StaticStrategy.java:127: Line has trailing spaces. Audit done. Regards, Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 11 March 2014 03:00 To: dev@cloudstack.apache.org Subject: [VOTE] Apache CloudStack 4.3.0 (seventh round) Hi All, I've created a 4.3.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip- us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 Commit: ec4db7bbff60f0be96e39f51c0f17b12e0de440c List of changes: New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ PGP release keys (signed using 94BE0D7C): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pro cedure Vote will be open for 36 hours (Thursday evening PST 8:00 PM) For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 traininghttp://shapeblue.com/cloudstack- training/ 18th-19th February 2014, Brazil. Classroomhttp://shapeblue.com/cloudstack
RE: cherry-pick to 4.3 request
Done From: Alena Prokharchyk Sent: Friday, March 07, 2014 6:46 PM To: Animesh Chaturvedi; dev@cloudstack.apache.org Subject: cherry-pick to 4.3 request Animesh, could you please cherry-pick one more commit for VPC, from forward to 4.3 branch? 164ea3e84f6f282006e66725f22cd2246f0be8f8 CloudStackCLOUDSTACK-6214 VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied -Alena.
RE: [4.3][Cherry-pick] realhostip changes
Done -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Sunday, March 09, 2014 2:08 PM To: dev@cloudstack.apache.org Subject: [4.3][Cherry-pick] realhostip changes Animesh - please pick the commit below from 4.3-forward into 4.3. This is for CLOUDSTACK-6204. 2fe7aeea23ddef25224e3e248f0a91513a14811f John
RE: 4.3 vote
-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
Sent: Friday, March 07, 2014 1:08 PM
To: dev@cloudstack.apache.org
Subject: RE: 4.3 vote
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Friday, March 07, 2014 8:41 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.3 vote
I have a review request sitting at https://reviews.apache.org/r/18392/
- that works for me but I don't know if it's breaking AWSAPI
functionality. Would love it if somebody more familiar with that
module could test. I'd rather not just check that in and see what happens.
[Animesh] I agree we cannot checkin especially so late in release unless we
are absolutely sure.
Animesh, I know you put a ton of work into these RCs and I hate
holding you up,
[Animesh] Well you are not holding me up. It's a community release not just
mine :)
but here's my train of thought: packaging/centos63/package.sh is broken
because one of the RPMs it attempts to build is for awsapi. No self-
respecting enterprise (I hope, dream) is going to drop non-packaged
(deb, rpm, whatever) code on production systems. So if that packaging
ability is broken, there's a good chance enterprises can't use the new code.
[Animesh] John while you can reproduce the issue but
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-package-rpm/
has been building successfully. Can we not use that? I guess this may have
been an issue for prior releases too but has not blocked folks.
[Animesh] Folks given that Jenkins build is successful I will proceed with RC
Just got an idea to see if Apache's Sonatype has a valid mirror, and
it does, at least for some[1]. So I'll go down that path this AM as
well, in case my patch above doesn't work.
John
1: https://repository.apache.org/index.html#nexus-search;quick~mex
On Mar 6, 2014, at 11:04 PM, Animesh Chaturvedi
animesh.chaturv...@citrix.com wrote:
Ok so how do we get past this? This should have been pre-existing as
dependency has been broken for a long time and I am not sure if this
should block our next RC.
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Thursday, March 06, 2014 4:14 PM
To: dev@cloudstack.apache.org
Subject: Re: 4.3 vote
David was seeing this as well. This is is a documented problem at
https://issues.apache.org/jira/browse/RAMPART-393.
I just spun up a VM at AWS using a 64 bit amazon linux api. Ran the
commands below, got same errors:
1 sudo yum update
2 yum install git java-1.7.0-openjdk-devel
3 git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git
4 wget http://www.dsgnwrld.com/am/maven/maven-
3/3.2.1/binaries/apache-maven-3.2.1-bin.tar.gz
5 tar xvf apache-maven-3.2.1-bin.tar.gz
6 export PATH=$PATH:~/apache-maven-3.2.1/bin/
7 cd cloudstack/
8 mvn -P deps
9 mvn clean install -Pawsapi
I suspect the Citrix devs are sitting behind Nexus or other maven mirror?
John
On Mar 6, 2014, at 3:13 PM, Animesh Chaturvedi
animesh.chaturv...@citrix.commailto:animesh.chaturv...@citrix.com
wrote:
Folks anyone else seeing this? I want to build RC soon and wanted
to confirm if this is an issue or not and if so if we can get a fix
right away
-Original Message-
From: Prachi Damle [mailto:prachi.da...@citrix.com]
Sent: Thursday, March 06, 2014 1:20 PM
To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
Subject: RE: 4.3 vote
John,
I could not reproduce this broken build on 4.3 after wiping out my
entire repository.
1. rm -rf ~/.m2/repository
2. mvn clean install -Pawsapi
My build is successful.
Can someone who is able to reproduce this check this further?
Prachi
[INFO]
---
--
---
[INFO] Reactor Summary:
[INFO]
[INFO] Apache CloudStack . SUCCESS
[1:53.957s] [INFO] Apache CloudStack Maven Conventions Parent
SUCCESS [0.089s] [INFO] Apache CloudStack Framework -
Managed Context . SUCCESS [28.189s] [INFO] Apache CloudStack
Utils ... SUCCESS [1:06.368s] [INFO] Apache
CloudStack Framework ... SUCCESS [0.303s]
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
[27.125s] [INFO] Apache CloudStack Framework - Configuration
... SUCCESS [5.878s] [INFO] Apache CloudStack API
.
SUCCESS [55.346s] [INFO] Apache CloudStack Framework - REST
SUCCESS [16.891s] [INFO] Apache CloudStack
Framework
- IPC . SUCCESS [11.845s] [INFO] Apache CloudStack
Cloud Engine SUCCESS [0.072s] [INFO] Apache
CloudStack Cloud Engine API
