date:20170509

Re: [Openstack] Cinder policy.json

2017-05-09 Thread Remo Mattei

Have you looked at this

https://blueprints.launchpad.net/cinder/+spec/public-volumes

Inviato da iPhone

> Il giorno 09 mag 2017, alle ore 07:10, "ch...@foxmail.com" 
>  ha scritto:
> 
> Hello:
> I want everyone be able to access a volume I created in cinder as admin, 
> so I changed /etc/cinder/policy.json as bellow, but it won't work. Why? And 
> how to do it?
> Thanks!
> policy.json
> 
> 
> {
> "context_is_admin": "role:admin",
> "admin_or_owner":  "is_admin:True or project_id:%(project_id)s",
> "default": "",
> 
> "admin_api": "is_admin:True",
> 
> "volume:create": "",
> "volume:delete": "",
> "volume:get": "",
> "volume:get_all": "",
> "volume:get_volume_metadata": "",
> "volume:delete_volume_metadata": "",
> "volume:update_volume_metadata": "",
> "volume:get_volume_admin_metadata": "rule:admin_api",
> "volume:update_volume_admin_metadata": "rule:admin_api",
> "volume:get_snapshot": "",
> "volume:get_all_snapshots": "",
> "volume:create_snapshot": "",
> "volume:delete_snapshot": "",
> "volume:update_snapshot": "",
> "volume:extend": "",
> "volume:update_readonly_flag": "",
> "volume:retype": "",
> "volume:update": "",
> 
> "volume_extension:types_manage": "rule:admin_api",
> "volume_extension:types_extra_specs": "rule:admin_api",
> "volume_extension:access_types_qos_specs_id": "rule:admin_api",
> "volume_extension:access_types_extra_specs": "rule:admin_api",
> "volume_extension:volume_type_access": "",
> "volume_extension:volume_type_access:addProjectAccess": "rule:admin_api",
> "volume_extension:volume_type_access:removeProjectAccess": 
> "rule:admin_api",
> "volume_extension:volume_type_encryption": "rule:admin_api",
> "volume_extension:volume_encryption_metadata": "",
> "volume_extension:extended_snapshot_attributes": "",
> "volume_extension:volume_image_metadata": "",
> 
> "volume_extension:quotas:show": "",
> "volume_extension:quotas:update": "rule:admin_api",
> "volume_extension:quotas:delete": "rule:admin_api",
> "volume_extension:quota_classes": "rule:admin_api",
> "volume_extension:quota_classes:validate_setup_for_nested_quota_use": 
> "rule:admin_api",
> 
> "volume_extension:volume_admin_actions:reset_status": "rule:admin_api",
> "volume_extension:snapshot_admin_actions:reset_status": "rule:admin_api",
> "volume_extension:backup_admin_actions:reset_status": "rule:admin_api",
> "volume_extension:volume_admin_actions:force_delete": "rule:admin_api",
> "volume_extension:volume_admin_actions:force_detach": "rule:admin_api",
> "volume_extension:snapshot_admin_actions:force_delete": "rule:admin_api",
> "volume_extension:backup_admin_actions:force_delete": "rule:admin_api",
> "volume_extension:volume_admin_actions:migrate_volume": "rule:admin_api",
> "volume_extension:volume_admin_actions:migrate_volume_completion": 
> "rule:admin_api",
> 
> "volume_extension:volume_host_attribute": "rule:admin_api",
> "volume_extension:volume_tenant_attribute": "",
> "volume_extension:volume_mig_status_attribute": "rule:admin_api",
> "volume_extension:hosts": "rule:admin_api",
> "volume_extension:services:index": "rule:admin_api",
> "volume_extension:services:update" : "rule:admin_api",
> 
> "volume_extension:volume_manage": "rule:admin_api",
> "volume_extension:volume_unmanage": "rule:admin_api",
> 
> "volume_extension:capabilities": "rule:admin_api",
> 
> "volume:create_transfer": "",
> "volume:accept_transfer": "",
> "volume:delete_transfer": "",
> "volume:get_all_transfers": "",
> 
> "volume_extension:replication:promote": "rule:admin_api",
> "volume_extension:replication:reenable": "rule:admin_api",
> 
> "volume:enable_replication": "rule:admin_api",
> "volume:disable_replication": "rule:admin_api",
> "volume:failover_replication": "rule:admin_api",
> "volume:list_replication_targets": "rule:admin_api",
> 
> "backup:create" : "",
> "backup:delete": "",
> "backup:get": "",
> "backup:get_all": "",
> "backup:restore": "",
> "backup:backup-import": "rule:admin_api",
> "backup:backup-export": "rule:admin_api",
> 
> "snapshot_extension:snapshot_actions:update_snapshot_status": "",
> "snapshot_extension:snapshot_manage": "rule:admin_api",
> "snapshot_extension:snapshot_unmanage": "rule:admin_api",
> 
> "consistencygroup:create" : "group:nobody",
> "consistencygroup:delete": "group:nobody",
> "consistencygroup:update": "group:nobody",
> "consistencygroup:get": "group:nobody",
> "consistencygroup:get_all": "group:nobody",
> 
> "consistencygroup:create_cgsnapshot" : "group:nobody",
> "consistencygroup:delete_cgsnapshot": "group:nobody",
> "consistencygroup:get_cgsnapshot": "group:nobody",
> "consistencygroup:get_all_cgsnapshots": "group:nobody",
> 
> "scheduler_extension:sched

Re: [Openstack] [designate] Synchronize bind9 backend

2017-05-09 Thread Lars-Erik Helander

Hi Graham,

We were using the designate version in newton bit is now using ocata, however 
the behaviour is the same (i.e. no synch)
Can I look for traces of the period synchs in some log file?
Is there some config parameter that controls the sunch?

/Lars

On 2017-05-04, 14:23, "Graham Hayes"  wrote:

On 03/05/17 10:51, Lars-Erik Helander wrote:
> We are using designate with a bind9 backend in a newton based Openstack
> system.
> 
> When the designate processes and the bind9 process are restarted they
> get out of synch. The zones in designate are no longer in bind9. How can
> I get the bind9 backend to get synchronized after a restart?
> 
>  
> 
> /Lars

Designate should run a periodic sync to check that all the zones are on
the bind9 server - what version of Designate are you using?

- Graham

> 
> 
> ___
> Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Cinder policy.json

2017-05-09 Thread ch...@foxmail.com

Hello:
I want everyone be able to access a volume I created in cinder as admin, so 
I changed /etc/cinder/policy.json as bellow, but it won't work. Why? And how to 
do it?
Thanks!
policy.json


{
"context_is_admin": "role:admin",
"admin_or_owner":  "is_admin:True or project_id:%(project_id)s",
"default": "",

"admin_api": "is_admin:True",

"volume:create": "",
"volume:delete": "",
"volume:get": "",
"volume:get_all": "",
"volume:get_volume_metadata": "",
"volume:delete_volume_metadata": "",
"volume:update_volume_metadata": "",
"volume:get_volume_admin_metadata": "rule:admin_api",
"volume:update_volume_admin_metadata": "rule:admin_api",
"volume:get_snapshot": "",
"volume:get_all_snapshots": "",
"volume:create_snapshot": "",
"volume:delete_snapshot": "",
"volume:update_snapshot": "",
"volume:extend": "",
"volume:update_readonly_flag": "",
"volume:retype": "",
"volume:update": "",

"volume_extension:types_manage": "rule:admin_api",
"volume_extension:types_extra_specs": "rule:admin_api",
"volume_extension:access_types_qos_specs_id": "rule:admin_api",
"volume_extension:access_types_extra_specs": "rule:admin_api",
"volume_extension:volume_type_access": "",
"volume_extension:volume_type_access:addProjectAccess": "rule:admin_api",
"volume_extension:volume_type_access:removeProjectAccess": "rule:admin_api",
"volume_extension:volume_type_encryption": "rule:admin_api",
"volume_extension:volume_encryption_metadata": "",
"volume_extension:extended_snapshot_attributes": "",
"volume_extension:volume_image_metadata": "",

"volume_extension:quotas:show": "",
"volume_extension:quotas:update": "rule:admin_api",
"volume_extension:quotas:delete": "rule:admin_api",
"volume_extension:quota_classes": "rule:admin_api",
"volume_extension:quota_classes:validate_setup_for_nested_quota_use": 
"rule:admin_api",

"volume_extension:volume_admin_actions:reset_status": "rule:admin_api",
"volume_extension:snapshot_admin_actions:reset_status": "rule:admin_api",
"volume_extension:backup_admin_actions:reset_status": "rule:admin_api",
"volume_extension:volume_admin_actions:force_delete": "rule:admin_api",
"volume_extension:volume_admin_actions:force_detach": "rule:admin_api",
"volume_extension:snapshot_admin_actions:force_delete": "rule:admin_api",
"volume_extension:backup_admin_actions:force_delete": "rule:admin_api",
"volume_extension:volume_admin_actions:migrate_volume": "rule:admin_api",
"volume_extension:volume_admin_actions:migrate_volume_completion": 
"rule:admin_api",

"volume_extension:volume_host_attribute": "rule:admin_api",
"volume_extension:volume_tenant_attribute": "",
"volume_extension:volume_mig_status_attribute": "rule:admin_api",
"volume_extension:hosts": "rule:admin_api",
"volume_extension:services:index": "rule:admin_api",
"volume_extension:services:update" : "rule:admin_api",

"volume_extension:volume_manage": "rule:admin_api",
"volume_extension:volume_unmanage": "rule:admin_api",

"volume_extension:capabilities": "rule:admin_api",

"volume:create_transfer": "",
"volume:accept_transfer": "",
"volume:delete_transfer": "",
"volume:get_all_transfers": "",

"volume_extension:replication:promote": "rule:admin_api",
"volume_extension:replication:reenable": "rule:admin_api",

"volume:enable_replication": "rule:admin_api",
"volume:disable_replication": "rule:admin_api",
"volume:failover_replication": "rule:admin_api",
"volume:list_replication_targets": "rule:admin_api",

"backup:create" : "",
"backup:delete": "",
"backup:get": "",
"backup:get_all": "",
"backup:restore": "",
"backup:backup-import": "rule:admin_api",
"backup:backup-export": "rule:admin_api",

"snapshot_extension:snapshot_actions:update_snapshot_status": "",
"snapshot_extension:snapshot_manage": "rule:admin_api",
"snapshot_extension:snapshot_unmanage": "rule:admin_api",

"consistencygroup:create" : "group:nobody",
"consistencygroup:delete": "group:nobody",
"consistencygroup:update": "group:nobody",
"consistencygroup:get": "group:nobody",
"consistencygroup:get_all": "group:nobody",

"consistencygroup:create_cgsnapshot" : "group:nobody",
"consistencygroup:delete_cgsnapshot": "group:nobody",
"consistencygroup:get_cgsnapshot": "group:nobody",
"consistencygroup:get_all_cgsnapshots": "group:nobody",

"scheduler_extension:scheduler_stats:get_pools" : "rule:admin_api"
}



ch...@foxmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Cinder policy.json

2017-05-09 Thread ch...@foxmail.com

Hello:
I want every one can access a volume I created in cinder as admin, so I 
changed /etc/cinder/policy.json as bellow, but it won't work. Why? And how to 
do it?
Thanks!
policy.json


{
"context_is_admin": "role:admin",
"admin_or_owner":  "is_admin:True or project_id:%(project_id)s",
"default": "",

"admin_api": "is_admin:True",

"volume:create": "",
"volume:delete": "",
"volume:get": "",
"volume:get_all": "",
"volume:get_volume_metadata": "",
"volume:delete_volume_metadata": "",
"volume:update_volume_metadata": "",
"volume:get_volume_admin_metadata": "rule:admin_api",
"volume:update_volume_admin_metadata": "rule:admin_api",
"volume:get_snapshot": "",
"volume:get_all_snapshots": "",
"volume:create_snapshot": "",
"volume:delete_snapshot": "",
"volume:update_snapshot": "",
"volume:extend": "",
"volume:update_readonly_flag": "",
"volume:retype": "",
"volume:update": "",

"volume_extension:types_manage": "rule:admin_api",
"volume_extension:types_extra_specs": "rule:admin_api",
"volume_extension:access_types_qos_specs_id": "rule:admin_api",
"volume_extension:access_types_extra_specs": "rule:admin_api",
"volume_extension:volume_type_access": "",
"volume_extension:volume_type_access:addProjectAccess": "rule:admin_api",
"volume_extension:volume_type_access:removeProjectAccess": "rule:admin_api",
"volume_extension:volume_type_encryption": "rule:admin_api",
"volume_extension:volume_encryption_metadata": "",
"volume_extension:extended_snapshot_attributes": "",
"volume_extension:volume_image_metadata": "",

"volume_extension:quotas:show": "",
"volume_extension:quotas:update": "rule:admin_api",
"volume_extension:quotas:delete": "rule:admin_api",
"volume_extension:quota_classes": "rule:admin_api",
"volume_extension:quota_classes:validate_setup_for_nested_quota_use": 
"rule:admin_api",

"volume_extension:volume_admin_actions:reset_status": "rule:admin_api",
"volume_extension:snapshot_admin_actions:reset_status": "rule:admin_api",
"volume_extension:backup_admin_actions:reset_status": "rule:admin_api",
"volume_extension:volume_admin_actions:force_delete": "rule:admin_api",
"volume_extension:volume_admin_actions:force_detach": "rule:admin_api",
"volume_extension:snapshot_admin_actions:force_delete": "rule:admin_api",
"volume_extension:backup_admin_actions:force_delete": "rule:admin_api",
"volume_extension:volume_admin_actions:migrate_volume": "rule:admin_api",
"volume_extension:volume_admin_actions:migrate_volume_completion": 
"rule:admin_api",

"volume_extension:volume_host_attribute": "rule:admin_api",
"volume_extension:volume_tenant_attribute": "",
"volume_extension:volume_mig_status_attribute": "rule:admin_api",
"volume_extension:hosts": "rule:admin_api",
"volume_extension:services:index": "rule:admin_api",
"volume_extension:services:update" : "rule:admin_api",

"volume_extension:volume_manage": "rule:admin_api",
"volume_extension:volume_unmanage": "rule:admin_api",

"volume_extension:capabilities": "rule:admin_api",

"volume:create_transfer": "",
"volume:accept_transfer": "",
"volume:delete_transfer": "",
"volume:get_all_transfers": "",

"volume_extension:replication:promote": "rule:admin_api",
"volume_extension:replication:reenable": "rule:admin_api",

"volume:enable_replication": "rule:admin_api",
"volume:disable_replication": "rule:admin_api",
"volume:failover_replication": "rule:admin_api",
"volume:list_replication_targets": "rule:admin_api",

"backup:create" : "",
"backup:delete": "",
"backup:get": "",
"backup:get_all": "",
"backup:restore": "",
"backup:backup-import": "rule:admin_api",
"backup:backup-export": "rule:admin_api",

"snapshot_extension:snapshot_actions:update_snapshot_status": "",
"snapshot_extension:snapshot_manage": "rule:admin_api",
"snapshot_extension:snapshot_unmanage": "rule:admin_api",

"consistencygroup:create" : "group:nobody",
"consistencygroup:delete": "group:nobody",
"consistencygroup:update": "group:nobody",
"consistencygroup:get": "group:nobody",
"consistencygroup:get_all": "group:nobody",

"consistencygroup:create_cgsnapshot" : "group:nobody",
"consistencygroup:delete_cgsnapshot": "group:nobody",
"consistencygroup:get_cgsnapshot": "group:nobody",
"consistencygroup:get_all_cgsnapshots": "group:nobody",

"scheduler_extension:scheduler_stats:get_pools" : "rule:admin_api"
}



ch...@foxmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to utilize Neutron independently with veths

2017-05-09 Thread duhongwei

Thanks Dan!


I have to write a customized CNI plugin for our product, so it's better if I 
know more operation details about how to interact with Neutron manually 
(consider myself as Nova). Therefore Kuryr is not my best option right now, but 
it's cool!


Regards,
Dastan
 
-- Original --
From:  "Vallachorum Tyranorum";
Date:  Tue, May 9, 2017 04:08 PM
To:  "duhongwei"; 
"openstack"; 

Subject:  Re: [Openstack] How to utilize Neutron independently with veths

 
Hi,

Please take a look at Kuryr. Maybe this is what you are looking for.


Dan. 


On Tue, May 9, 2017 at 10:17 AM duhongwei  wrote:

Hi everyone,


I'm new to OpenStack and currently interested in the Neutron part of it. What 
I'm seeking is some advice about how to utilize Neutron independently, to build 
a virtual network, for Docker containers maybe.


Suppose I've already got Neutron and Keystone installed on controller node and 
compute nodes. I guess the following steps are required to test a virtual 
network.


1) create a network
2) create a subnet
3) create two pairs of veths (each pair represents a vm)
for each pair of them:
4) create a port for one end of the veth pair (passing veth's mac address as a 
parameter)
5) attach another end of the veth pair to ovs bridge
6) ping from one veth pair to another


The above is my general idea, don't know if it is correct and don't know the 
operation details either.
Expecting your suggestions, any links are appreciated.


Regards,
Dastan


___
 Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openstack@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to utilize Neutron independently with veths

2017-05-09 Thread Vallachorum Tyranorum

Hi,

Please take a look at Kuryr . Maybe
this is what you are looking for.

Dan.

On Tue, May 9, 2017 at 10:17 AM duhongwei  wrote:

> Hi everyone,
>
> I'm new to OpenStack and currently interested in the Neutron part of it.
> What I'm seeking is some advice about how to utilize Neutron independently,
> to build a virtual network, for Docker containers maybe.
>
> Suppose I've already got Neutron and Keystone installed on controller node
> and compute nodes. I guess the following steps are required to test a
> virtual network.
>
> 1) create a *network*
> 2) create a *subnet*
> 3) create two pairs of veths (each pair represents a vm)
> *for each pair of them*:
> 4) create a *port *for one end of the veth pair (passing veth's mac
> address as a parameter)
> 5) attach another end of the veth pair to ovs bridge
> 6) ping from one veth pair to another
>
> The above is my general idea, don't know if it is correct and don't know
> the operation details either.
> Expecting your suggestions, any links are appreciated.
>
> Regards,
> Dastan
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Best link or way to deploy openstack on three Machines?

2017-05-09 Thread Waqas Riaz

Hi Asif,

You can try Fuel. A minimal installation of one control node, two compute
nodes can be installed with fuel master node installed in VM. Below are
some useful links.

https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide.html
https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide.html

Cheers,
Waqas Riaz


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Waqas Riaz



On Mon, May 8, 2017 at 2:58 PM, Muhammad Asif  wrote:

> Hi Geeks,
>
> I need to deploy private cloud for private user and for DevOps.
> I am following this link for deploying openstack. but it is not smooth.
> Actually I need to configure Cloud Foundry (PAAS) on Openstack. I have
> spent 2 month but no to avail.
>
> https://docs.openstack.org/ocata/install-guide-ubuntu/
>
> Please share the most useful link.
>
>
> Regards
> M.Asif
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] cloud-init not start ini ubuntu 17.04

2017-05-09 Thread Eugen Block


Hi,


my problem is while I build the based image, cloud-init process won't run
while based image booting, there is no log record in /var/log/syslog (in
this case ubuntu), and its just happend in 17.04.


so are the services up and running within your instances?
Please check "systemctl status cloud-*" if all required services are  
up and running. Maybe they have to be enabled ans started first. Just  
because you didn't have to do it manually before, doesn't mean this  
will never change ;-)


Regards,
Eugen


Zitat von Adhi Priharmanto :


Hi Eugen,

Based on this guide, just install and reconfigure datasource of cloud-init
if needed.

https://docs.openstack.org/image-guide/ubuntu-image.html

my problem is while I build the based image, cloud-init process won't run
while based image booting, there is no log record in /var/log/syslog (in
this case ubuntu), and its just happend in 17.04.

I had build custom image with 16.04 and 16.10, and it's fine, just install
the cloud-init package needed.



On Fri, May 5, 2017 at 1:26 PM, Eugen Block  wrote:


You have to make sure that cloud-init is enabled and running in your base
instance. Then snapshot that VM and launch another instance from the new
image, provide some user-data to test it.
Cloud-init is a tool for initial configuration of new instances, that's
why you would have to execute these steps manually if you configure your
first VM to be a new base image. So all the magic will be (hopefully)
visible if you launch a new VM.


Regards,
Eugen


Zitat von Adhi Priharmanto :

Hi Bob,


yes I'm following those tutorial, creating glance image from existing vm
xenserver.

   - build from scratch VM using "16.04 template" and "other installation
   media"
   - update & upgrade the VM OS
   - installing cloud-init package, no change of cloud-init configuration
   and using the default setting of cloud-init
   - reboot the VM for testing the cloud-init and no output showing
   cloud-init activity, there is no process associated with cloud-init in
   "/var/log/syslog"
   - export the vdi, compress the VHD, upload to glance
   - start instance using the custom image, just get the IP address. To
   gather instance metadata, "cloud-init init" must be executed manually
after
   instance completely booting.


On Thu, May 4, 2017 at 11:32 PM, Bob Ball  wrote:

Hi Adhi,




Did you follow a guide, such as http://citrix-openstack.
siteleaf.net/posts/generating-images-for-xenserver-in-openstack/ for
generating the image?  If not, how was the image generated?



What exactly is the output from the 17.04 image you’re using?



Thanks,



Bob



*From:* Adhi Priharmanto [mailto:adhi@gmail.com]
*Sent:* 03 May 2017 16:36
*To:* openstack 
*Subject:* [Openstack] cloud-init not start ini ubuntu 17.04



hi all,

I just created ubuntu 17.04 custom image for working with openstack
xenserver, after installing & update+upgrade ubuntu 17.04 base OS, I
installed cloud-init, then reboot it to test cloud-init, but I can't see
cloud-init process during the ubuntu 17.04 OS boot.

Is there anyone can help or give a suggest for me ?


--

Cheers,





*Adhi Priharmanto*

about.me/a_dhi

[image: http://d13pix9kaak6wt.cloudfront.net/signature/colorbar.png]



+62-812-82121584 <+62%20812-8212-1584>







--
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584





--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
k
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
k





--
Cheers,



[image: --]
Adhi Priharmanto
[image: http://]about.me/a_dhi

+62-812-82121584




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] How to utilize Neutron independently with veths

2017-05-09 Thread duhongwei

Hi everyone,


I'm new to OpenStack and currently interested in the Neutron part of it. What 
I'm seeking is some advice about how to utilize Neutron independently, to build 
a virtual network, for Docker containers maybe.


Suppose I've already got Neutron and Keystone installed on controller node and 
compute nodes. I guess the following steps are required to test a virtual 
network.


1) create a network
2) create a subnet
3) create two pairs of veths (each pair represents a vm)
for each pair of them:
4) create a port for one end of the veth pair (passing veth's mac address as a 
parameter)
5) attach another end of the veth pair to ovs bridge
6) ping from one veth pair to another


The above is my general idea, don't know if it is correct and don't know the 
operation details either.
Expecting your suggestions, any links are appreciated.


Regards,
Dastan___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Cinder policy.json

Re: [Openstack] [designate] Synchronize bind9 backend

[Openstack] Cinder policy.json

[Openstack] Cinder policy.json

Re: [Openstack] How to utilize Neutron independently with veths

Re: [Openstack] How to utilize Neutron independently with veths

Re: [Openstack] Best link or way to deploy openstack on three Machines?

Re: [Openstack] cloud-init not start ini ubuntu 17.04

[Openstack] How to utilize Neutron independently with veths

9 matches

Site Navigation

Mail list logo

Footer information