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 <shadow...@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 <t...@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 <j...@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 <shadow...@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.,
>>
>
>
