Re: Committee to Sort through CCC Presentation Submissions

[Tutkowski, Mike]

Hi everyone,

This note is a follow-up to this discussion thread.

Around the middle of April, the CloudStack PMC received an e-mail indicating 
(to our surprise) that we needed to provide the people organizing Montreal’s 
upcoming ApacheCon (which includes the CloudStack Collab Conf) with a schedule 
by Thursday, April 19th.

As this was sooner than we had expected, we were not able to get the group of 
people who had volunteered to look at the CFP together for a call.

Giles, Will Stevens, and I ended up examining the 29 submissions. We determined 
that four people had submitted more than one proposal (which is perfectly fine, 
of course). Being that we needed to respond to the organizers quickly, we 
decided if we limited each person who submitted one or more abstracts to only 
one that we would then be able to accept a presentation from each person.

Please let me know if you have questions.

Thanks,
Mike

On 3/27/18, 1:39 PM, "Tutkowski, Mike"  wrote:

Hi everyone,

As you may be aware, this coming September in Montreal, the CloudStack 
Community will be hosting the CloudStack Collaboration Conference:

http://ca.cloudstackcollab.org/

Even though the event is six months away, we are on a tight schedule with 
regards to the Call For Participation (CFP):

https://www.apachecon.com/acna18/schedule.html

If you are interested in submitting a talk, please do so before March 30th.

That being said, as usual, we will have need of a small committee to sort 
through these presentation submissions.

If you are interested in helping out in this process, please reply to this 
message.

Thanks!
Mike

Re: [DISCUSS] CloudStack graceful shutdown

[Rafael Weingärtner]

Thanks for the feedback Ilya. Then, we would only need to adapt this new
feature introduced by you and ShapeBlue.


On Sat, Apr 21, 2018 at 4:03 PM, ilya musayev 
wrote:

> Rafael
>
> What you are suggesting - was already implemented. We've created Load
> Balancing algorithms - but we did not take into account the LB algo for
> maintenance (yet). Rohit and ShapeBlue were the developers behind the
> feature.
>
> What needs to happen is a tweak to LB Algorithms to become MS maintenance
> aware - or create new LB Algos altogether. Essentially we need to merge
> your work and this feature. Please read the FS below.
>
> Functional Spec:
>
>
> The new CA framework introduced basic support for comma-separated
> list of management servers for agent, which makes an external LB
> unnecessary.
>
> This extends that feature to implement LB sorting algorithms that
> sorts the management server list before they are sent to the agents.
> This adds a central intelligence in the management server and adds
> additional enhancements to Agent class to be algorithm aware and
> have a background mechanism to check/fallback to preferred management
> server (assumed as the first in the list). This is support for any
> indirect agent such as the KVM, CPVM and SSVM agent, and would
> provide support for management server host migration during upgrade
> (when instead of in-place, new hosts are used to setup new mgmt server).
>
> This FR introduces two new global settings:
>
>- indirect.agent.lb.algorithm: The algorithm for the indirect agent LB.
>- indirect.agent.lb.check.interval: The preferred host check interval
>for the agent's background task that checks and switches to agent's
>preferred host.
>
> The indirect.agent.lb.algorithm supports following algorithm options:
>
>- static: use the list as provided.
>- roundrobin: evenly spreads hosts across management servers based on
>host's id.
>- shuffle: (pseudo) randomly sorts the list (not recommended for
>production).
>
> Any changes to the global settings - indirect.agent.lb.algorithm and
> host does not require restarting of the mangement server(s) and the
> agents. A message bus based system dynamically reacts to change in these
> global settings and propagates them to all connected agents.
>
> Comma-separated management server list is propagated to agents on
> following cases:
>
>- Addition of a host (including ssvm, cpvm systevms).
>- Connection or reconnection by the agents to a management server.
>- After admin changes the 'host' and/or the
>'indirect.agent.lb.algorithm' global settings.
>
> On the agent side, the 'host' setting is saved in its properties file as:
> host=@.
>
> First the agent connects to the management server and sends its current
> management server list, which is compared by the management server and
> in case of failure a new/update list is sent for the agent to persist.
>
> From the agent's perspective, the first address in the propagated list
> will be considered the preferred host. A new background task can be
> activated by configuring the indirect.agent.lb.check.interval which is
> a cluster level global setting from CloudStack and admins can also
> override this by configuring the 'host.lb.check.interval' in the
> agent.properties file.
>
> Every time agent gets a ms-host list and the algorithm, the host specific
> background check interval is also sent and it dynamically reconfigures
> the background task without need to restart agents.
>
> Note: The 'static' and 'roundrobin' algorithms, strictly checks for the
> order as expected by them, however, the 'shuffle' algorithm just checks
> for content and not the order of the comma separate ms host addresses.
>
> Regards
> ilya
>
>
> On Fri, Apr 20, 2018 at 1:01 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > Is that management server load balancing feature using static
> > configurations? I heard about it on the mailing list, but I did not
> follow
> > the implementation.
> >
> > I do not see many problems with agents reconnecting. We can implement in
> > agents (not just KVM, but also system VMs) a logic that instead of using
> a
> > static pool of management servers configured in a properties file, they
> > dynamically request a list of available management servers via that list
> > management servers API method. This would require us to configure agents
> > with a load balancer URL that executes the balancing between multiple
> > management servers.
> >
> > I am +1 to remove the need for that VIP, which executes the load balance
> > for connecting agents to management servers.
> >
> > On Fri, Apr 20, 2018 at 4:41 PM, ilya musayev <
> > ilya.mailing.li...@gmail.com>
> > wrote:
> >
> > > Rafael and Community
> > >
> > > All is well and good and i think we are thinking along the similar
> lines
> > -
> > > the only issue that i see right now with any approach is KVM Agents (or
> > > direct agents) 

Re: Default API response type: XML -> JSON

[Rohit Yadav]

This can possibly fail some environments, but it depends on feedback from users.

One option is to introduce global settings, (but we've got many of those) such 
that it's set to XML set in ConfigKey, but when a new env is installed (as part 
of server xml/sql) we set it to JSON.


Another option is, do a survey, leave it open for few months and based on the 
feedback decide to accept the PR.


- Rohit






From: Rafael Weingärtner 
Sent: Tuesday, April 24, 2018 4:05:30 PM
To: users
Cc: dev
Subject: Re: Default API response type: XML -> JSON

No problem Marc, but I still do not think that having a parameter is an
overkill. My view is that if there is a decision to be made (regarding the
default response type for requests), if we (as developers) take this
decision (hardcode it), why not externalize it? I do not see as overkill,
it is a matter of having a flexible tool.

I do not think that forcing to have a response type would be a good thing
now. It would break requests that do not have it.


On Tue, Apr 24, 2018 at 7:14 AM, Marc-Aurèle Brothier 
wrote:

> @rafael - I think it's overkill to have this as a configuration option. We
> should have one default response type, or maybe not have a default one and
> enforce the use of the response type the client is willing to receive.
>
> On Mon, Apr 23, 2018 at 3:39 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I do think it is an interesting proposal. I have been thinking, and what
> if
> > we do something different; what about a global parameter where the root
> > admin can define the default serialization mechanism (XML, JSON, RDF,
> > others...)? The default value could be XML to maintain backward
> > compatibility. Then, it is up to the root admin to define this behavior.
> >
> >
> > On Mon, Apr 23, 2018 at 10:34 AM, Marc-Aurèle Brothier <
> ma...@exoscale.ch>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I thought it would be good to move from XML to JSON by default in the
> > > response of the API if no response type is sent to the server along
> with
> > > the request. I'm wondering that's the opinion of people on the mailing
> > > list.
> > >
> > > Moreover, if anyone knows a tool working with the API in XML can you
> list
> > > them, so I could check the code and see if the change can be done
> without
> > > breaking it.
> > >
> > > PR to change default response type: (
> > > https://github.com/apache/cloudstack/pull/2593).
> > > If this change would cause more trouble, or is not needed in your
> > opinion,
> > > I don't mind to close the PR.
> > >
> > > Kind regards,
> > > Marc-Aurèle
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



--
Rafael Weingärtner

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [DISCUSS] 4.11.1.0 release

[Rohit Yadav]

Thanks Wido (and Gabriel)!


Update - I'll spend next 2.5 weeks to triage issues, work with everyone to 
reviews, fix, test PRs. The rough timeline is to work on that and try an get 
RC1 voting started by the end of next month, maybe as early as mid-May (14-15 
May). If RC1 voting is not started by mid-May, then Daan/Paul will carry the RM 
effort forward.


Therefore, dev/users please report issues, help with bug reporting or testing 
latest 4.11, or report issues you've found in 4.11.0.0.


- Rohit






From: Wido den Hollander 
Sent: Monday, April 23, 2018 12:22:37 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.11.1.0 release



On 04/20/2018 03:03 PM, Rohit Yadav wrote:
> All,
>
>
> I would like to kick a discussion around the next 4.11 LTS minor/bugfix 
> release - 4.11.1.0.
>
>
> Many of us have tried to discuss, triage and fix issues that you've reported 
> both on users and dev MLs. It is possible that some of those discussions have 
> not met a conclusion/solution yet. Therefore, first check if your reported 
> issue has been reported or fixed towards the 4.11.1.0 milestone from here:
>
> https://github.com/apache/cloudstack/milestone/5
>
>
> In case it is not reported/fixed, please report your issues with details here 
> (perhaps giving link to an existing email thread):
>
> https://github.com/apache/cloudstack/issues
>
>
> When you do report an issue (or send a PR), especially upgrade or regression 
> related, please do use the milestone 4.11.1.0 along with suitable labels 
> which will make it easier to triage them.
>
>
> I still don't have an exact timeline to share yet but I'll try to get that 
> shared as soon as next week. Thanks.
>

Thank you for your effort! Me and Gabriel will spend some time on
helping getting 4.11.1 out of the door!

Wido

>
> - Rohit
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: Default API response type: XML -> JSON

[Rene Moser]

I am +1 but with a versioned API (v2) because this would break most
likely many API implementations.

René

On 04/23/2018 03:34 PM, Marc-Aurèle Brothier wrote:
> Hi everyone,
> 
> I thought it would be good to move from XML to JSON by default in the
> response of the API if no response type is sent to the server along with
> the request. I'm wondering that's the opinion of people on the mailing list.
> 
> Moreover, if anyone knows a tool working with the API in XML can you list
> them, so I could check the code and see if the change can be done without
> breaking it.
> 
> PR to change default response type: (
> https://github.com/apache/cloudstack/pull/2593).
> If this change would cause more trouble, or is not needed in your opinion,
> I don't mind to close the PR.
> 
> Kind regards,
> Marc-Aurèle
> 

Re: Default API response type: XML -> JSON

[Ron Wheeler]

The time would be better spent on fixing the docs.

It is time to turn Cloudstack into a production quality product with 
documentation that actually reflects the quality of the design and 
functionality.


At the moment you have 2 people willing to work on the docs waiting for 
a committer to decide that professional documentation matters.


This proposal seems to make the product more complicated with no 
substantial benefit.
Parsing XML is a well-known technology and switching to JSON does not 
seem to reduce the code required or reduce the complexity of the code.


If there is a desire to me "more modern", fix the documentation.


On 24/04/2018 6:14 AM, Marc-Aurèle Brothier wrote:

@rafael - I think it's overkill to have this as a configuration option. We
should have one default response type, or maybe not have a default one and
enforce the use of the response type the client is willing to receive.

On Mon, Apr 23, 2018 at 3:39 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:


I do think it is an interesting proposal. I have been thinking, and what if
we do something different; what about a global parameter where the root
admin can define the default serialization mechanism (XML, JSON, RDF,
others...)? The default value could be XML to maintain backward
compatibility. Then, it is up to the root admin to define this behavior.


On Mon, Apr 23, 2018 at 10:34 AM, Marc-Aurèle Brothier 
wrote:


Hi everyone,

I thought it would be good to move from XML to JSON by default in the
response of the API if no response type is sent to the server along with
the request. I'm wondering that's the opinion of people on the mailing
list.

Moreover, if anyone knows a tool working with the API in XML can you list
them, so I could check the code and see if the change can be done without
breaking it.

PR to change default response type: (
https://github.com/apache/cloudstack/pull/2593).
If this change would cause more trouble, or is not needed in your

opinion,

I don't mind to close the PR.

Kind regards,
Marc-Aurèle




--
Rafael Weingärtner



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Default API response type: XML -> JSON

[Rafael Weingärtner]

No problem Marc, but I still do not think that having a parameter is an
overkill. My view is that if there is a decision to be made (regarding the
default response type for requests), if we (as developers) take this
decision (hardcode it), why not externalize it? I do not see as overkill,
it is a matter of having a flexible tool.

I do not think that forcing to have a response type would be a good thing
now. It would break requests that do not have it.


On Tue, Apr 24, 2018 at 7:14 AM, Marc-Aurèle Brothier 
wrote:

> @rafael - I think it's overkill to have this as a configuration option. We
> should have one default response type, or maybe not have a default one and
> enforce the use of the response type the client is willing to receive.
>
> On Mon, Apr 23, 2018 at 3:39 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I do think it is an interesting proposal. I have been thinking, and what
> if
> > we do something different; what about a global parameter where the root
> > admin can define the default serialization mechanism (XML, JSON, RDF,
> > others...)? The default value could be XML to maintain backward
> > compatibility. Then, it is up to the root admin to define this behavior.
> >
> >
> > On Mon, Apr 23, 2018 at 10:34 AM, Marc-Aurèle Brothier <
> ma...@exoscale.ch>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I thought it would be good to move from XML to JSON by default in the
> > > response of the API if no response type is sent to the server along
> with
> > > the request. I'm wondering that's the opinion of people on the mailing
> > > list.
> > >
> > > Moreover, if anyone knows a tool working with the API in XML can you
> list
> > > them, so I could check the code and see if the change can be done
> without
> > > breaking it.
> > >
> > > PR to change default response type: (
> > > https://github.com/apache/cloudstack/pull/2593).
> > > If this change would cause more trouble, or is not needed in your
> > opinion,
> > > I don't mind to close the PR.
> > >
> > > Kind regards,
> > > Marc-Aurèle
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

Re: Default API response type: XML -> JSON

[Marc-Aurèle Brothier]

@rafael - I think it's overkill to have this as a configuration option. We
should have one default response type, or maybe not have a default one and
enforce the use of the response type the client is willing to receive.

On Mon, Apr 23, 2018 at 3:39 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I do think it is an interesting proposal. I have been thinking, and what if
> we do something different; what about a global parameter where the root
> admin can define the default serialization mechanism (XML, JSON, RDF,
> others...)? The default value could be XML to maintain backward
> compatibility. Then, it is up to the root admin to define this behavior.
>
>
> On Mon, Apr 23, 2018 at 10:34 AM, Marc-Aurèle Brothier 
> wrote:
>
> > Hi everyone,
> >
> > I thought it would be good to move from XML to JSON by default in the
> > response of the API if no response type is sent to the server along with
> > the request. I'm wondering that's the opinion of people on the mailing
> > list.
> >
> > Moreover, if anyone knows a tool working with the API in XML can you list
> > them, so I could check the code and see if the change can be done without
> > breaking it.
> >
> > PR to change default response type: (
> > https://github.com/apache/cloudstack/pull/2593).
> > If this change would cause more trouble, or is not needed in your
> opinion,
> > I don't mind to close the PR.
> >
> > Kind regards,
> > Marc-Aurèle
> >
>
>
>
> --
> Rafael Weingärtner
>