[Openstack-operators] Provider Networks Help
Hi, I have setup an OpenStack cloud using OpenStack-Ansible but having issues setting up networking. I need to have two external networks e.g. 10.1.0.0/24 & 10.2.0.0/24 that are accessible to instances. I have two bridges, br-ex and br-ex2, setup on the infra nodes that are able to access the 10.1.0.0/24 & 10.2.0.0/24 ranges respectively. I am guessing that I need to add another two flat networks to the provider_networks? The current provider_networks configuration is: provider_networks: - network: container_bridge: "br-mgmt" container_type: "veth" container_interface: "eth1" ip_from_q: "container" type: "raw" group_binds: - all_containers - hosts is_container_address: true is_ssh_address: true - network: container_bridge: "br-vxlan" container_type: "veth" container_interface: "eth10" ip_from_q: "tunnel" type: "vxlan" range: "1:1000" net_name: "vxlan" group_binds: - neutron_linuxbridge_agent - network: container_bridge: "br-vlan" container_type: "veth" container_interface: "eth12" host_bind_override: "eth12" type: "flat" net_name: "flat" group_binds: - neutron_linuxbridge_agent - network: container_bridge: "br-vlan" container_type: "veth" container_interface: "eth11" type: "vlan" range: "101:200,301:400" net_name: "vlan" group_binds: - neutron_linuxbridge_agent - network: container_bridge: "br-storage" container_type: "veth" container_interface: "eth2" ip_from_q: "storage" type: "raw" group_binds: - glance_api - cinder_api - cinder_volume - nova_compute Cheers, Matt --- Dr Matt John Engineer (Service Delivery - COMSC) School of Computer Science & Informatics Cardiff University, 5 The Parade, Cardiff, CF24 3AA Tel: +44 2920 876536 joh...@cardiff.ac.uk The University welcomes correspondence in Welsh or English. Corresponding in Welsh will not lead to any delay. Dr Matt John Peiriannydd (Cyflwyno Gwasanaeth - COMSC) Ysgol Cyfrifiadureg a Gwybodeg Prifysgol Caerdydd, 5 The Parade, Caerdydd, CF24 3AA Ffôn : +44 2920 876536 joh...@caerdydd.ac.uk Mae'r Brifysgol yn croesawu gohebiaeth yn Gymraeg neu'n Saesneg. Ni fydd gohebu yn Gymraeg yn creu unrhyw oedi. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] getting back onto our IRC channel
On 2018-08-09 09:56:47 +0200 (+0200), Thierry Carrez wrote: > Jeremy Stanley wrote: > > [...] > > It does indeed sound like you might be caught up in the > > aforementioned SASL-only network blacklist (I wasn't even aware of > > it until this ML thread) which Freenode staff seem to be using to > > help block the spam onslaught from some known parts of the Internet. > > [...] > > Yes, the Freenode blacklist blocks most cloud providers IP blocks. My own > instance (running on an OpenStack public cloud) is also required to use > SASL. That's very useful detail--thanks! I simply didn't notice it because I've been authenticating via SASL for years already on any IRC networks which support that, but I can definitely see how that might catch a bunch of our participants off-guard (especially given our "cloud" focus in this community). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Openstack Version discovery with the cli client.
Thanks ! I think the command I was looking for is: "openstack versions show" But for example for Neutron I get just version v2.0 from Newton to Pike, that tells me very little. The use case is when testing Kubernetes on Openstack, a lot of kubernetes users cannot tell easily the version of Openstack they are testing on. Because things like the LBaaS are so different between Openstack releases that version v2.0 tells too little. Often it is good to know what is the version of the Openstack cloud to identify bugs on launchpad. Cheers, Saverio Il giorno mar 7 ago 2018 alle ore 15:48 George Mihaiescu ha scritto: > > Hi Saverio, > > I think only the API versions supported by some of the endpoint are > discoverable, as described here: > https://wiki.openstack.org/wiki/VersionDiscovery > > curl https://x.x.x.x:9292/image > curl https://x.x.x.x:8774/compute > > > Cheers, > George > > On Tue, Aug 7, 2018 at 9:30 AM, Saverio Proto wrote: >> >> Hello Jimmy, >> >> thanks for your help. If I understand correctly the answer you linked, >> that helps if you operate the cloud and you have access to the >> servers. Then of course you can call nova-manage. >> >> But being a user of a public cloud without having access the the >> infrastructure servers ... how do you do that ? >> >> thanks >> >> Saverio >> >> >> >> Il giorno mar 7 ago 2018 alle ore 15:09 Jimmy McArthur >> ha scritto: >> > >> > Hey Saverio, >> > >> > This answer from ask.openstack.org should have what you're looking for: >> > https://ask.openstack.org/en/question/45513/how-to-find-out-which-version-of-openstack-is-installed/at >> > >> > Once you get the release number, you have to look it up here to match >> > the release date: https://releases.openstack.org/ >> > >> > I had to use this the other day when taking the COA. >> > >> > Cheers, >> > Jimmy >> > >> > Saverio Proto wrote: >> > > Hello, >> > > >> > > This is maybe a super trivial question bit I have to admit I could not >> > > figure it out. >> > > >> > > Can the user with the openstack cli client discover the version of >> > > Openstack that is running ? >> > > >> > > For example in kubernetes the kubectl version command returns the >> > > version of the client and the version of the cluster. >> > > >> > > For Openstack I never managed to discover the backend version, and >> > > this could be useful when using public clouds. >> > > >> > > Anyone knows how to do that ? >> > > >> > > thanks >> > > >> > > Saverio >> > > >> > > ___ >> > > OpenStack-operators mailing list >> > > OpenStack-operators@lists.openstack.org >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?
Exactly. And I agree, it seems like hw_architecture should dictate which emulator is chosen, but as you mentioned its currently not. I'm not sure if this is a bug and it's supposed to 'just work', or just something that was never fully implemented (intentionally) and would be more of a feature request/suggestion for a later version. The docs are kind of sparse in this area. What are your thoughts? I can open a bug if you think the scope is reasonable. --- v/r Chris Apsey bitskr...@bitskrieg.net https://www.bitskrieg.net On 2018-08-08 06:40 PM, Matt Riedemann wrote: On 8/8/2018 2:42 PM, Chris Apsey wrote: qemu-system-arm, qemu-system-ppc64, etc. in our environment are all x86 packages, but they perform system-mode emulation (via dynamic instruction translation) for those target environments. So, you run qemu-system-ppc64 on an x86 host in order to get a ppc64-emulated VM. Our use case is specifically directed at reverse engineering binaries and fuzzing for vulnerabilities inside of those architectures for things that aren't built for x86, but there are others. If you were to apt-get install qemu-system and then hit autocomplete, you'd get a list of archiectures that qemu can emulate on x86 hardware - that's what we're trying to do incorporate. We still want to run normal qemu-x86 with KVM virtualization extensions, but we ALSO want to run the other emulators without the KVM virtualization extensions in order to have more choice for target environments. So to me, openstack would interpret this by checking to see if a target host supports the architecture specified in the image (it does this correctly), then it would choose the correct qemu-system-xx for spawning the instance based on the architecture flag of the image, which it currently does not (it always choose qemu-system-x86_64). Does that make sense? OK yeah now I'm following you - running ppc guests on an x86 host (virt_type=qemu rather than kvm right?). I would have thought the hw_architecture image property was used for this somehow to configure the arch in the guest xml properly, like it's used in a few places [1][2][3]. See [4], I'd think we'd set the guest.arch but don't see that happening. We do set the guest.os_type though [5]. [1] https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L4649 [2] https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L4927 [3] https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/blockinfo.py#L257 [4] https://libvirt.org/formatcaps.html#elementGuest [5] https://github.com/openstack/nova/blob/c18b1c1bd646d7cefa3d3e4b25ce59460d1a6ebc/nova/virt/libvirt/driver.py#L5196 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] getting back onto our IRC channel
Jeremy Stanley wrote: [...] It does indeed sound like you might be caught up in the aforementioned SASL-only network blacklist (I wasn't even aware of it until this ML thread) which Freenode staff seem to be using to help block the spam onslaught from some known parts of the Internet. [...] Yes, the Freenode blacklist blocks most cloud providers IP blocks. My own instance (running on an OpenStack public cloud) is also required to use SASL. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
