Re: Domain admin can not view details for templates for parent domain

[Ivan Kudryavtsev]

Hello again, this regression is introduced by my code modification. Sorry
for a mess.

2017-12-07 14:40 GMT+07:00 Ivan Kudryavtsev :

> Hello, Devs.
>
> This is related to basic zone with SGs and ACS 4.10.
>
> I created ROOT/user1 domain and user1 account of role DomainAdmin for that
> domain respectively. In ROOT domain I have default network as usual and
> several templates. But, domain admin unable to view details for those
> templates and listNetworks.
>
> Cloudstack states:
>
> Acct[162b26e6-052a-43bb-9116-acb7555b6d7d-user1] does not have permission
> to operate within domain id=6764b1a8-c69b-11e7-bdcf-0242ac110004
>
> The similar result is for
>
> Acct[162b26e6-052a-43bb-9116-acb7555b6d7d-user1] does not have permission
> to operate within domain id=6764b1a8-c69b-11e7-bdcf-0242ac110004
>
> listNetworks API. Please, could you comment if it's expected behaviour or
> not? Anyway with that bug creation of VM is impossible inside of domains
> via UI because of security notice which leads to inability to select SG.
>
> 2017-12-07 14:38:30,518 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-014419b8) (logid:a4a3658e) ===START===  91.221.61.126
> -- GET  command=listNetworks&trafficType=Guest&zoneId=
> d477bb3f-3592-4503-8f2a-da3d878dd476&response=json&_=1512632310523
> 2017-12-07 14:38:30,530 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-1:ctx-014419b8 ctx-9e325b66) (logid:a4a3658e) Ignoring
> paremeter displaynetwork as the caller is not authorized to pass it in
> 2017-12-07 14:38:30,532 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-1:ctx-014419b8 ctx-9e325b66) (logid:a4a3658e) Ignoring
> paremeter displaynetwork as the caller is not authorized to pass it in
>
> I also checked dynamic role config for domain admin. Everything is OK.
> listNetworks is allowed, but I believe it's related to self-owned objects.
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks Software, Ltd.
> Cell: +7-923-414-1515
> WWW: http://bitworks.software/ 
>
>


-- 
With best regards, Ivan Kudryavtsev
Bitworks Software, Ltd.
Cell: +7-923-414-1515
WWW: http://bitworks.software/ 

4.11 : Physical networking migration ; Config Drive support

[Kris Sterckx]

Hi all,


I would like to raise attention to 2 features which are pending 4.11, which
received great appreciation from some of you and which from Nuage
perspective we see great interest to from large operators also. They are :

   - Physical networking migration, or : Migrate networks to a new physical
   network
   Jira : https://issues.apache.org/jira/browse/CLOUDSTACK-10024
   Design doc :
   
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Physical+Networking+Migration
   PR : https://github.com/apache/cloudstack/pull/2259
   - Config Drive support :
   Jira : https://issues.apache.org/jira/browse/CLOUDSTACK-9813
   Design doc : https://issues.apache.org/jira/browse/CLOUDSTACK-9813
   PR : https://github.com/apache/cloudstack/pull/2097


I would like to emphasis first that both features are generic solutions,
not tight to any SDN solution whatsoever.


Regarding network migration support : to anyone interested in this
capability, please review the design doc and/or the PR. The more buy-in we
get to this large amount of work we spent to this, the more appraisal you
give to the guys who spent the work. We hope to get this PR merged in
before end of the year.


Regarding config drive support : as already discussed in the Miami
Collaboration conference in May, this PR gives you fully standard
cloud-init support using the OpenStack configdrive datasource provider and
it works like a charm. We received very positive feedback to this. There
has been discussion about the storage strategy though and people voted for
storing the iso's at primary storage rather than at secondary storage.
There has been further work spent on this by Frank Maximus and there has
been some review of that but i am not sure we still want to include that
change still in 4.11. Frankly my proposal would be we take an incremental
approach and start larger validation cycles for the outstanding PR and
approach further evolution of it in the next release cycle. Open to your
feedback.  In any case I would find it a missed opportunity if config drive
would eventually not find its way into 4.11 at all.  Again, we see great
interest in this.  Potentially we could declare it as experimental support,
to be enabled via an advanced setting - just an idea. In that way more
people get can a sense of how it works and provide feedback. Another item
to notice is that as Nuage team does not have XenServer deployments, we
have no facility to verify the PR with XenServer. Helping out on that would
be appreciated also.



Thanks,


Kris