date:20140930

Re: [openstack-dev] 2 Minute tokens

2014-09-30 Thread Chmouel Boudjnah

On Wed, Oct 1, 2014 at 3:47 AM, Adam Young  wrote:

> 1.  Identify the roles for the APIs that Cinder is going to be calling on
> swift based on Swifts policy.json

FYI: there is no Swifts policy.json in mainline code, there is one external
middleware available that provides it here
https://github.com/cloudwatt/swiftpolicy.git.

Chmouel
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Core Reviewer Change

2014-09-30 Thread Noorul Islam K M

Adrian Otto  writes:

> Solum Core Reviewer Team,
>
> I propose the following change to our core reviewer group:
>
> -lifeless (Robert Collins) [inactive]
> +murali-allada (Murali Allada)
> +james-li (James Li)
>
> Please let me know your votes (+1, 0, or -1).
>

+1

Regards,
Noorul

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Core Reviewer Change

2014-09-30 Thread Julien Vey

+1

2014-10-01 0:20 GMT+02:00 Angus Salkeld :

> +1
> On 01/10/2014 3:08 AM, "Adrian Otto"  wrote:
>
>> Solum Core Reviewer Team,
>>
>> I propose the following change to our core reviewer group:
>>
>> -lifeless (Robert Collins) [inactive]
>> +murali-allada (Murali Allada)
>> +james-li (James Li)
>>
>> Please let me know your votes (+1, 0, or -1).
>>
>> Thanks,
>>
>> Adrian
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-09-30 Thread Alex Glikson

This sounds related to the discussion on the 'Nova clustered hypervisor 
driver' which started at Juno design summit [1]. Talking to another 
OpenStack should be similar to talking to vCenter. The idea was that the 
Cells support could be refactored around this notion as well. 
Not sure whether there have been any active progress with this in Juno, 
though.

Regards,
Alex


[1] 
http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c#
[2] 
https://etherpad.openstack.org/p/juno-nova-clustered-hypervisor-support




From:   joehuang 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   30/09/2014 04:08 PM
Subject:[openstack-dev] [all] [tc] Multi-clouds integration by 
OpenStack cascading



Hello, Dear TC and all, 

Large cloud operators prefer to deploy multiple OpenStack instances(as 
different zones), rather than a single monolithic OpenStack instance 
because of these reasons:
 
1) Multiple data centers distributed geographically;
2) Multi-vendor business policy;
3) Server nodes scale up modularized from 00's up to million;
4) Fault and maintenance isolation between zones (only REST interface);
 
At the same time, they also want to integrate these OpenStack instances 
into one cloud. Instead of proprietary orchestration layer, they want to 
use standard OpenStack framework for Northbound API compatibility with 
HEAT/Horizon or other 3rd ecosystem apps.
 
We call this pattern as "OpenStack Cascading", with proposal described by 
[1][2]. PoC live demo video can be found[3][4].
 
Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in 
the OpenStack cascading. 
 
Kindly ask for cross program design summit session to discuss OpenStack 
cascading and the contribution to Kilo. 

Kindly invite those who are interested in the OpenStack cascading to work 
together and contribute it to OpenStack. 
 
(I applied for “other projects” track [5], but it would be better to 
have a discussion as a formal cross program session, because many core 
programs are involved )
 
 
[1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
[2] PoC source code: https://github.com/stackforge/tricircle
[3] Live demo video at YouTube: 
https://www.youtube.com/watch?v=OSU6PYRz5qY
[4] Live demo video at Youku (low quality, for those who can't access 
YouTube)：http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html
[5] 
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395.html

 
Best Regards
Chaoyi Huang ( Joe Huang )
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] VPNaaS site to site connection down.

2014-09-30 Thread masoom alam

Hi Paul,

Apologies for late response. I was having throat infection.




> Can you show the ipsec-site-connection-create command used on each end?
>


neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id
myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1
--peer-address  --peer-id  --peer-cidr
10.2.0.0/24 --psk secret


   - In the above command: --peer-address is the public ip of the node
   having devstack setup -- you can call it devstack West
   - --peer-id: we are giving the ip of the q-router


Make sense?



> Can you show the topology with IP addresses used (and indicate how the two
> clouds are connected)?
> Are you using devstack? Two physical nodes? How are they interconnected?
>

We are using exactly the same topology as shown below even the floating ip
addresses are same one mentioned below. However, Our Internet gateway is a
public ip. Similarly, other Internet GW is also a public ip.

  (10.1.0.0/24 - DevStack *East*)
  |
  |  10.1.0.1
 [Quantum Router]
  |  172.24.4.226
  |
  |  172.24.4.225
 [Internet GW]
  |
  |
 [Internet GW]
  | 172.24.4.232
  |
  | 172.24.4.233
 [Quantum Router]
  |  10.2.0.1
  |
 (10.2.0.0/24 DevStack *West*)



> First thing would be to ensure that you can ping from one host to another
> over the public IPs involved. You can then go to the namespace of the
> router and see if you can ping the public I/F of the other end’s router.
>

We can ping anything on the host having devstack setup for example
google.com, but GW of the other host. However, we cannot ping from within
the CirrOS instance. I have run the traceroute command and we are reaching
till 172.24.4.225 but not beyond this point. BTW we did some other
experiments as well. For example, when we tried to explicitly link our
br-ex (172.24.4.225) with eth0 (Internet GW), machine got corrupted. Same
is the issue if we do a hard reboot, Neutron gets corrupted :)


>
> You can look at the screen-q-vpn.log (assuming devstack used) to see if
> any errors during setup.
>
> Note: When I stack, I turn off neutron security groups and then set nova
> security groups to allow SSH and ICMP. I imagine the alternative would be
> to setup neutron security groups to allow these two protocols.
>
> I didn’t quite follow what you meant by "Please note that my two devstack
> nodes are on different public addresses, so scenario is a little different
> than the one described here:
> https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall”. Can you
> elaborate (showing the commands and topology will help)?
>
> Germy,
>
> I have created this BP during Juno (unfortunately no progress on it
> however), regarding being able to see more status information for
> troubleshooting:
> https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-status-report
>
> It was targeted for vendor implementations, but would include reference
> implementation status too. Right now, if a VPN connection negotiation
> fails, there’s no indication of what went wrong.
>
> Regards,
>
>
> PCM (Paul Michali)
>
> MAIL …..…. p...@cisco.com
> IRC ……..… pcm_ (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>
>
>
> On Sep 29, 2014, at 1:38 AM, masoom alam  wrote:
>
> Hi Germy
>
> We cannot ping the public interface of the 2nd devstack setup (devstack
> West). From our Cirros instance (First devstack -- devstack east), we can
> ping our own public ip, but cannot ping the other public ip. I think
> problem lies here, if we are reaching the devstack west, how can we make a
> VPN connection
>
> Our topology looks like:
>
> *CirrOS --->Qrouter>Public IP ---publicIP>Qrouter->CirrOS*
> _ _
>devstack EASTdevstack WEST
>
>
> Also it is important to note that we are not able to ssh the instance
> private ip, without *sudo ip netns qrouter id *so this means we cannot
> even ssh with floating ip.
>
>
> it seems there is a problem in firewall or iptables.
>
> Please guide
>
>
>
> On Sunday, September 28, 2014, Germy Lure  wrote:
>
>> Hi,
>>
>> masoom:
>> I think firstly you can just check that if you could ping from left to
>> right without installing VPN connection.
>> If it worked, then you should cat the system logs to confirm the
>> configure's OK.
>> You can ping and tcpdump to dialog where packets are blocked.
>>
>> stackers:
>> I think we should give mechanism to show the cause when vpn-connection is
>> down. At least, we could extend an attribute to explain this. Maybe the
>> VPN-incubator project is a chance?
>>
>> BR,
>> Germy
>>
>>
>> On Sat, Sep 27, 2014 at 7:04 PM, masoom alam 
>> wrote:
>>
>>> Hi Every one,
>>>
>>> I am trying to establish the VPN conne

Re: [openstack-dev] 2 Minute tokens

2014-09-30 Thread Adam Young

> This is comparable to the HEAT use case that Keystone Trusts were
originally designed to solve.

>
> If the glance client knows the roles required to perform those
operations, it could create the trust up front, with the Glance
Service user as the trustee; the trustee execute the trust when it
needs the token.

>
> Are there other cases besides the glance one that require long lived
tokens?

Cinder backups. These do many swift operations over a long period,
often hours. They should probably be converted to trusts, but I'd need
some guidance do so.

1. Identify the roles for the APIs that Cinder is going to be calling
on swift based on Swifts policy.json
2. The user Creates trust: this could be done by the cinder client.
The create trust call is here:

trustee user is the Cinder service user
trustor user is the actual human being (or reasonable facimile thereof)
that needs this work done.

https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-trust-ext.md#create-trust-post-os-trusttrusts

impersonation should only be set if the API requires the tokens user_id
to reflect the trustor. I know that swift was one of the use cases for
impersonation, but I don't think it is required.

Expiration date time is optional, but probably appropriate; chose a
value that is guaranteed to be long enough for the workflow, but that
still limits the window for attack. If this backup routinely takes 12
hours, perhaps 24 hours is appropriate.

When the user requests the Cinder backup, they will have to include the
trust ID in the request. The cinder endpoint, prior to making a call to
Swift, will get a token from Keystone, passing in the trust id as per

86 matches

Mail list logo