incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: devcloud-kvm (and marvin bugs)
Date Tue, 15 Jan 2013 02:37:30 GMT
You can use tools/devcloud/devcloud-advanced.cfg and the normal devcloud2.
I haven't updated the image on the kvm one yet.
On Jan 14, 2013 7:27 PM, "prasanna" <tsp@apache.org> wrote:

> Hey Marcus, Is the latest  devcloud-kvm image you shared via the wiki
> up to date? I'll try it out and see why traffic labels failed to
> configure. Thanks,
>
> On 15 January 2013 06:55, Marcus Sorensen <shadowsor@gmail.com> wrote:
> > I've now got a config for regular devcloud in
> > tools/devcloud/devcloud-advanced.cfg, this works for me to deploy a fully
> > working advanced network zone, except for the traffic labels. If I go in
> > and manually fix the traffic labels to be as shown in the config, then
> > restart management server/system vms, everything works. This is given a
> > default virtualbox install where the nat is 10.0.3.2.  Public VMs end up
> on
> > the 10.0.3 network, and isolated networks carve out new tagged
> > vlans/bridges on the 192.168.56.0 network.
> >
> > I've also got a version for my devcloud-kvm that needs the same labels
> > settings to work, once that's done I'll update the docs and the
> > devcloud-kvm should be ready to go.
> >
> > On Mon, Jan 14, 2013 at 11:53 AM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
> >
> >> Thanks. I've tested the vlan stuff and it seems to work. Now I'm stuck
> on
> >> the traffic labels. My config deploys but my traffic labels all show
> 'Use
> >> default network'. My script generated the following:
> >>
> >> {
> >>     "zones": [
> >>         {
> >>             "localstorageenabled": "true",
> >>             "name": "testzone",
> >>             "guestcidraddress": "10.1.1.0/24",
> >>             "dns1": "8.8.8.8",
> >>             "physical_networks": [
> >>                 {
> >>                     "broadcastdomainrange": "Zone",
> >>                     "vlan": "3900-4000",
> >>                     "name": "eth0",
> >>                     "traffictypes": [
> >>                         {
> >>                             "xen": "Pool-wide network associated with
> >> eth0",
> >>                             "typ": "Management"
> >>                         },
> >>                         {
> >>                             "xen": "Pool-wide network associated with
> >> eth0",
> >>                             "typ": "Guest"
> >>                         }
> >>                     ],
> >>                     "providers": [
> >>                         {
> >>                             "broadcastdomainrange": "ZONE",
> >>                             "name": "VirtualRouter"
> >>                         },
> >>                         {
> >>                             "broadcastdomainrange": "ZONE",
> >>                             "name": "VpcVirtualRouter"
> >>                         }
> >>                     ]
> >>                 },
> >>                 {
> >>                     "broadcastdomainrange": "Zone",
> >>                     "name": "eth1",
> >>                     "traffictypes": [
> >>                         {
> >>                             "xen": "Pool-wide network associated with
> >> eth1",
> >>                             "typ": "Public"
> >>                         }
> >>                     ],
> >>                     "providers": [
> >>                         {
> >>                             "broadcastdomainrange": "ZONE",
> >>                             "name": "VirtualRouter"
> >>                         }
> >>                     ]
> >>                 }
> >>             ],
> >>             "ipranges": [
> >>                 {
> >>                     "startip": "10.0.3.100",
> >>                     "endip": "10.0.3.199",
> >>                     "netmask": "255.255.255.0",
> >>                     "vlan": "untagged",
> >>                     "gateway": "10.0.3.2"
> >>                 }
> >>             ],
> >>             "networktype": "Advanced",
> >>             "pods": [
> >>                 {
> >>                     "endip": "192.168.56.249",
> >>                     "name": "testpod",
> >>                     "startip": "192.168.56.200",
> >>                     "netmask": "255.255.255.0",
> >>                     "clusters": [
> >>                         {
> >>                             "clustername": "testcluster",
> >>                             "hypervisor": "XenServer",
> >>                             "hosts": [
> >>                                 {
> >>                                     "username": "root",
> >>                                     "url": "http://192.168.56.10/",
> >>                                     "password": "password"
> >>                                 }
> >>                             ],
> >>                             "clustertype": "CloudManaged"
> >>                         }
> >>                     ],
> >>                     "gateway": "192.168.56.1"
> >>                 }
> >>             ],
> >>             "internaldns1": "8.8.4.4",
> >>             "secondaryStorages": [
> >>                 {
> >>                     "url": "nfs://192.168.56.10:/opt/storage/secondary"
> >>                 }
> >>             ]
> >>         }
> >>     ],
> >>     "dbSvr": {
> >>         "dbSvr": "127.0.0.1",
> >>         "passwd": "cloud",
> >>         "db": "cloud",
> >>         "port": 3306,
> >>         "user": "cloud"
> >>     },
> >>     "logger": [
> >>         {
> >>             "name": "TestClient",
> >>             "file": "/var/log/testclient.log"
> >>         },
> >>         {
> >>             "name": "TestCase",
> >>             "file": "/var/log/testcase.log"
> >>         }
> >>     ],
> >>     "mgtSvr": [
> >>         {
> >>             "mgtSvrIp": "192.168.56.10",
> >>             "port": 8096
> >>         }
> >>     ]
> >> }
> >>
> >>
> >> and my networks look like:
> >>
> >> root@devcloud:~/marvin# xe network-list
> >> uuid ( RO)                : 4f17b2b8-f7a8-0c2f-12b2-45bddeb63744
> >>           name-label ( RW): Host internal management network
> >>     name-description ( RW): Network on which guests will be assigned a
> >> private link-local IP address which can be used to talk XenAPI
> >>               bridge ( RO): xenapi
> >>
> >>
> >> uuid ( RO)                : 4948968a-3e67-fe53-29ad-099d74bac81c
> >>           name-label ( RW): cloud_link_local_network
> >>     name-description ( RW): link local network used by system vms
> >>               bridge ( RO): xapi0
> >>
> >>
> >> uuid ( RO)                : f1b661c0-d3a0-7e94-0302-9a306f798787
> >>           name-label ( RW): Pool-wide network associated with eth0
> >>     name-description ( RW):
> >>               bridge ( RO): xenbr0
> >>
> >>
> >> uuid ( RO)                : 585cc9f4-e11e-51eb-9b4b-bed2f71a8658
> >>           name-label ( RW): Pool-wide network associated with eth1
> >>     name-description ( RW):
> >>               bridge ( RO): xenbr1
> >>
> >>
> >> uuid ( RO)                : c1dbdb4c-16cb-5ce5-9026-5908e2463d20
> >>           name-label ( RW):
> VLAN-f1b661c0-d3a0-7e94-0302-9a306f798787-165
> >>     name-description ( RW):
> >>               bridge ( RO): xapi1
> >>
> >>
> >> uuid ( RO)                : b1e55bef-fe46-3a0b-ab0a-549121f42249
> >>           name-label ( RW):
> VLAN-f1b661c0-d3a0-7e94-0302-9a306f798787-149
> >>     name-description ( RW):
> >>               bridge ( RO): xapi2
> >>
> >>
> >> On Sun, Jan 13, 2013 at 2:04 AM, Prasanna Santhanam <tsp@apache.org
> >wrote:
> >>
> >>> I've fixed the problem of the same vlan applied to all the physical
> >>> networks with CLOUDSTACK-968 [1]. The vlan attribute went
> back-and-forth
> >>> b/w zone and phy. network when the physical-network concept was
> >>> introduced. Looks like I failed to fix marvin then.
> >>>
> >>> Also while fixing this I noticed our ZoneResponse still carries the
> >>> legacy 'vlan' that was given at zone level in 2.2. This is ending up
> >>> in marvin's response class too in createZoneResponse. Not sure if this
> >>> is still reqd because I didn't find any usage of that vlan. Posted
> >>> CLOUDSTACK-969 [2]
> >>>
> >>> The wiki documentation is also corrected along with the examples in
> >>> the sandbox which now show the use of traffic labels.
> >>>
> >>> Lastly, I've also committed a config generator script for devcloud-kvm
> >>> extending from the config you shared [3]
> >>>
> >>> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-968
> >>> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-969
> >>> [3] http://s.apache.org/rrZ
> >>>
> >>> Thanks,
> >>>
> >>> On Fri, Jan 11, 2013 at 01:05:55PM -0500, Prasanna Santhanam wrote:
> >>> > Marcus - Thanks for bringing these up:
> >>> >
> >>> > On Fri, Jan 11, 2013 at 12:41:08PM -0500, Marcus Sorensen wrote:
> >>> > > Let me verify that everything is working first :-)
> >>> > >
> >>> > > I've had a chance to play with some of the marvin stuff a bit,
and
> am
> >>> > > running into a few issues. Per the example on
> >>> > >
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Python
> >>> > > under
> >>> > > 'how do I generate it', if I copy that python script into devcloud
> >>> and run
> >>> > > it, I end up with the following broken globalConfig:
> >>> > >
> >>> > >     "globalConfig": [
> >>> > >         {
> >>> > >             "name": "name",
> >>> > >             "value": "value"
> >>> > >         },
> >>> > >         {
> >>> > >             "name": "name",
> >>> > >             "value": "value"
> >>> > >         }
> >>> > >     ],
> >>> >
> >>> > I'll fix this. The documentation is wrong. That should just be a
> >>> dictionary.
> >>> > You can check tools/marvin/marvin/sandbox/advanced/advanced_env.py
on
> >>> how you
> >>> > can simply get the config out of a properties file.
> >>> >
> >>> > >
> >>> > > If I delete that then the 431 goes away.
> >>> > >
> >>> > > Also, I don't see a way to edit the traffic labels on the advanced
> >>> network
> >>> > > stuff in marvin, that would be extremely useful.
> >>> >
> >>> > This can be done as follows:
> >>> >
> >>> > for eg:
> >>> > from
> tools/marvin/marvin/configGenerator.py:describe_setup_in_eip_mode()
> >>> >
> >>> > 418         pn = physical_network()
> >>> > 419         pn.name = "test-network"
> >>> > 420         pn.traffictypes = [traffictype("Guest", {"xen":
> >>> "cloud-guest"}), traffictype("Management"), traffictype("Public", {
> "xen":
> >>> "cloud-public"}    )]
> >>> > 421         pn.providers.extend([sgprovider, nsprovider])
> >>> > 422         z.physical_networks.append(pn)
> >>> >
> >>> > >
> >>> > > Lastly, It seems that if I set a vlan range for a zone, marvin
> >>> attempts to
> >>> > > set that vlan range for every physical network defined for the
> zone.
> >>> So the
> >>> > > first one succeeds, the second one fails. The vlan property should
> be
> >>> moved
> >>> > > up to be a member of the physical network as far as marvin is
> >>> concerned.
> >>> > > We're in the process of making changes that allow you to use the
> same
> >>> vlan
> >>> > > numbers on different physical networks anyway, since it's possible
> >>> that you
> >>> > > can have completely separate infrastructure on each nic.
> >>> > >
> >>> > You're right - I'll have the vlan move down to physical_network.
> >>> >
> >>> > >
> >>> > > On Fri, Jan 11, 2013 at 10:09 AM, John Kinsella <jlk@stratosec.co>
> >>> wrote:
> >>> > >
> >>> > > > very cool - hoping I can get a chance to test this out and
give
> some
> >>> > > > feedback within the next week or so.  Thanks!
> >>> > > >
> >>> > > > On Jan 10, 2013, at 10:53 AM, Marcus Sorensen <
> shadowsor@gmail.com>
> >>> wrote:
> >>> > > >
> >>> > > > > Guys,
> >>> > > > >  I'm writing up basic instructions on how to run a devcloud-kvm
> >>> virtual
> >>> > > > > machine, for KVM development. The setup is complete,
but I've
> run
> >>> into a
> >>> > > > > few things as far as configuration that I'd like some
help on.
> >>> > > > >
> >>> > > > > 1) running services. In the past I've just built rpms
and
> >>> installed them
> >>> > > > in
> >>> > > > > the devcloud-kvm. Not only does this not work on master
right
> >>> now, but it
> >>> > > > > takes an extra 60 seconds. With devcloud we run "mvn
-P
> >>> > > > developer,systemvm
> >>> > > > > clean install && mvn -pl :cloud-client-ui jetty:run",
I'm
> >>> assuming I'll
> >>> > > > > have to start the agent as well... or I guess my question
is
> how
> >>> that's
> >>> > > > > handled when a normal zone creation expects the agent
to be
> >>> installed on
> >>> > > > > the KVM host.
> >>> > > > >
> >>> > > > > 2) how to go about configuration. I'd like to have a
marvin
> >>> config that
> >>> > > > > does two physical networks and an advanced zone, but
I wasn't
> >>> able to get
> >>> > > > > anything but a 431 error when trying anything custom
with a
> >>> marvin cfg
> >>> > > > file
> >>> > > > > (both in the standard devcloud and here). I played with
the
> >>> sandbox
> >>> > > > example
> >>> > > > > at
> >>> > > > >
> >>> > > >
> >>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Testing+with+Pythonas
> >>> > > > > well as trying to create my own cfg file, and both resulted
in
> >>> 431 when
> >>> > > > > connecting to the management server for configuration.
> >>> > > >
> >>> > > > Stratosec - Secure Infrastructure as a Service
> >>> > > > o: 415.315.9385
> >>> > > > @johnlkinsella
> >>> > > >
> >>> > > >
> >>> >
> >>> > --
> >>> > Prasanna.,
> >>>
> >>> --
> >>> Prasanna.,
> >>>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message