[openstack-dev] [cinder], [cinder-driver] Request for new cinder driver

[Mardan Raghuwanshi]

Hello Team,

We develop cinder driver and supporting minimum features, but our driver
are not the part of openstack release. We also created blueprint for it.

I would like to understand the process to push the cinder driver with the
official release of openstack. What are the pre-requisites one needs to
fulfill to be part of the openstack release? so I'm looking at a clear
procedure required to be qualified to be a part of the openstack release?
Please let me know.


Thanks,

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

[openstack-dev] [Neutron][IPv6] Small feedback about Management Network & API Endpoints

[Martinx - ジェームズ]

Guys,

I'm running OpenStack IceHouse configured with IPv6 in almost every part of
it, I can say that both `Management Network` and `API Endpoints` works with
IPv6, but, there are still only three places that I am unable to use it
with IPv6, which is:


1- Metadata (no IPv6 here, the equivalent of 169.254.0.0/16 for IPv6 is the
subnet fe80::/64, am I right?);

2- VXLAN / GRE tunnels, precisely at `local_ip` in ml2_conf.ini (it doesn't
work when with IPv6);

3- Tenant subnet (IPv6 works with Flat Networks and statically/manually
configured, no SLAAC and no Neutron L3 with IPv6 yet).


NOTE: I still did not tested Heat, Cinder or Swift.


Everything else is working with IPv6!

Here is a few more details about my environment:

Controller's /etc/network/interface file:

---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#
# OpenStack API Endpoints
auto eth0
iface eth0 inet6 static
address 2804:29X:Y:dead::10
netmask 64
gateway 2804:29X:Y:dead::1
dns-domain tcmc.com.br
dns-search tcmc.com.br
dns-nameservers 2804:29X:4::1 2001:129X:2bX::1

# OpenStack - Management
auto eth1
iface eth1 inet6 static
address fddc:3c8c:6e8c:b129::10
netmask 64

# Legacy - Only required because of Metadata, it doesn't have an IPv6
# equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64)
iface eth1 inet static
address 192.168.5.10
netmask 24
---

Network Node /etc/network/interfaces file:

---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface.
auto lo
iface lo inet loopback

#
# Reachable from the Internet.
#

# The primary network interface. Node Internet access.
auto eth0
iface eth0 inet6 static
address 2804:29X:Y:dead::20
netmask 64
 gateway 2804:29X:Y:dead::1
dns-domain tcmc.com.br
dns-search tcmc.com.br
dns-nameservers 2804:290:4::1 2001:1291:2bf::1

#
# Unreachable from the Internet.
#

# OpenStack - Management
auto eth1
iface eth1 inet6 static
address fddc:3c8c:6e8c:b129::20
netmask 64

# Legacy - Only required because of Metadata, it doesn't have an IPv6
# equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64).
iface eth1 inet static
address 192.168.5.20
netmask 24

# VXLAN Traffic - Not working right now with IPv6.
auto eth2
iface eth2 inet6 static
address fda2:c917:cd2e:0552::20
netmask 64

# Legacy - Only required because Neutron doesn't support VXLAN tunnels on
top
# of a IPv6 network.
iface eth2 inet static
address 192.168.6.20
netmask 24

#
# Reachable from the Internet only from within each Namespace router.
#

# Bridge br-ex attached here, this is the "WAN Port" of tenant's routers.
auto eth3
iface eth3 inet manual
up ip addr add 0/0 dev eth3
 up ip link set dev $IFACE up
up ip link set $IFACE promisc on
 up ethtool --offload $IFACE gro off
down ip link set $IFACE promisc off
 down ip link set $IFACE down
---


Common /etc/hosts file across the Cloud:

---
127.0.0.1   localhost.localdomain   localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

# OpenStack APIs Endpoints
2804:29X:Y:dead::10 psuaa-1.tcmc.com.br psuaa-1
2804:29X:Y:dead::20 psuab-1.tcmc.com.br psuab-1
2804:29X:Y:dead::30 psuac-1.tcmc.com.br psuac-1
2804:29X:Y:dead::1000   psuah-1.tcmc.com.br psuah-1

# OpenStack Management - MySQL, RabbitMQ, SPICE, Glance...
fddc:3c8c:6e8c:b129::10 psuaa-1.mng.tcmc.com.br psuaa-1.mng
fddc:3c8c:6e8c:b129::20 psuab-1.mng.tcmc.com.br psuab-1.mng
fddc:3c8c:6e8c:b129::1000   psuah-1.mng.tcmc.com.br psuah-1.mng

# VXLAN Network - Project's subnet - DOESN'T WORK WITH IPv6
fda2:c917:cd2e:0552::20 psuab-1.vxlan.tcmc.com.br
psuab-1.vxlan
fda2:c917:cd2e:0552::1000   psuah-1.vxlan.tcmc.com.br
psuah-1.vxlan

# Cinder Network - iSCSI Traffic
fd72:3148:4c74:2f60::30 psuac-1.blk.tcmc.com.br psuac-1.blk
fd72:3148:4c74:2f60::1000   psuah-1.blk.tcmc.com.br psuah-1.blk
---

NOTE: Those private IPv6 subnets was generated here:
http://www.simpledns.com/private-ipv6.aspx

Then, for example, I configured `auth_host` under `[keystone_authtoken]`
poiting to `psuaa-1.mng.tcmc.com.br` and `auth_uri` poiting to
`http://psuaa-1.tcmc.com.br:5000`.

But, as I figured out, Metadata doesn't work with IPv6, which means that
`metadata_host / metadata_listen` is configured to `192.168.5.10` at
Controller's nova.conf (it doesn't work when I tried it with `
fddc:3c8c:6e8c:b129::10`) and, at my Network Node, the `local_ip` at
`ml2_conf.ini` points 

[openstack-dev] booting VM with customized kernel and rootfs image

[sonia verma]

Hi all

I have installed openstack using devstack.I'm able able to boot VM from the
opebstack dashboard onto the compute node.
Now i need to boot VM from the openstack dashboard(controller node) onto
compute node using customized kernel imae and rootfs.
Therefore my question is whether can we boot VM from controller node onto
compute node using the customized kernel and rootfs image.
Please help regarding this.



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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Collins, Sean]

On Thu, May 08, 2014 at 03:02:28PM EDT, Stephen Wong wrote:
> Hi Sean,
> 
> Perfect (I assume it is local time, i.e. 2:30pm EDT).
> 
> And I also assume this will be at the Neutron pod?
> 

Correct on both counts. See everyone soon!

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

Re: [openstack-dev] [Neutron][LBaaS] Discussion about a bug of health monitor

[Lingxian Kong]

Hi Dong:

IMO, apparently, the api-site and the implementation are inconsistent,
we should figure out how it's designed orignally and whether it has been
discussed in the ML before, maybe there's something we missed here. Just
see others' opinions.

P.S. most if not all of the core team may be drinking the beer in the
summit now, so you may need some time to get an answer. :)



2014-05-12 10:23 GMT+08:00 Dong Liu :

> Hi all:
>
> According to the neutron LBaaS api document[1], the attributes of health
> monitor, delay and
> timeout are both non-negative, and the timeout value must be less than
> the delay value.
>
> But in currently implementation, I can do these operations:
> - the timeout value could be negative
> - the timeout value could be less then delay value
>
> I'm not sure if this is a bug, because we have defined the delay value
> could not be negative
> already. If it is a bug, I will report the bug in launch and fix it. If
> not, is there anything
> specific reason?
>
> Thanks,
> Dong Liu
>
> [1]
> http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext_ops_health_monitor.html
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Mistral] Why keystone token validation fails in PyCharm, and how to fix it

[Dmitri Zimine]

The problem: Keystone authentication on MAC works from command line, but fails 
when run from PyCharm. And I want to run PyCharm to debug! 

The root cause: Keystone uses openssl cms which is only available in new 
openssl.  I installed openssl via brew, and got it in /usr/local/bin. Terminal 
works just fine because I have paths properly setup in /etc/paths file. But 
PyCharm and other non-terminal applications dont use it! 
 
The right solution: 
 create a file /etc/launchd.conf with the following line:
 setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
   
The hack solution is:
 sudo mv /usr/bin/openssl /usr/bin/openssl_bak
 sudo ln -s /usr/bin/local/openssl /usr/bin/openssl

DZ> 


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

Re: [openstack-dev] [sahara] Nominate Trevor McKay for sahara-core

[Alexander Ignatov]

+1

Thank you Trevor for your efforts are done in EDP!

Regards,
Alexander Ignatov



On 12 May 2014, at 17:31, Sergey Lukjanov  wrote:

> Hey folks,
> 
> I'd like to nominate Trevor McKay (tmckay) for sahara-core.
> 
> He is among the top reviewers of Sahara subprojects. Trevor is working
> on Sahara full time since summer 2013 and is very familiar with
> current codebase. His code contributions and reviews have demonstrated
> a good knowledge of Sahara internals. Trevor has a valuable knowledge
> of EDP part and Hadoop itself. He's working on both bugs and new
> features implementation.
> 
> Some links:
> 
> http://stackalytics.com/report/contribution/sahara-group/30
> http://stackalytics.com/report/contribution/sahara-group/90
> http://stackalytics.com/report/contribution/sahara-group/180
> https://review.openstack.org/#/q/owner:tmckay+sahara+AND+-status:abandoned,n,z
> https://launchpad.net/~tmckay
> 
> Sahara cores, please, reply with +1/0/-1 votes.
> 
> Thanks.
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Mirantis Inc.
> 
> ___
> 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] Introducing Project Graffiti

[Sundar, Murali]

Alex,

The concepts for Graffiti are very general and are not really tied to a 
specific use case like application-catalog. It is fundamentally a way to 
annotate any resource with metadata. For example, what standard way can we use 
to describe the capabilities of a compute host? How can that capability be 
referenced on images, host-aggregates, policies, flavors, etc. How can ISVs, 
vendors declare their unique capabilities and have it be associated with 
various objects? Say I create a machine image that uses certain libraries that 
can benefit from some specific HW capability? How can I declare that 
requirement and have it be applied during scheduling? What Graffiti allows a 
person to do is tag various resources in openstack with known metadata, and the 
metadata can then be used for any purpose. We demonstrate it being used to deal 
with extra specs in flavors, images etc.

You are welcome to our design session @ the summit http://youtu.be/f0SZtPgcxk4 
and we can discuss more, and talk about the demo code that we have working. If 
you are not able to make it to the session, please just email me and we can 
still meet and discuss this.

Thanks,
Murali


-Original Message-
From: Alexander Tivelkov [mailto:ativel...@mirantis.com] 
Sent: Tuesday, May 06, 2014 2:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Introducing Project Graffiti

Hi Travis,

It will be great to have your team join the artifact repository initiative. We 
are going to have a session at the summit ([1]) to discuss the design, and you 
most welcome to join. We'll publish the etherpad with brief agenda for this 
session later this week.


Speaking about Murano you've got a very good point: currently Murano's 
application catalog is very tightly coupled with the workflow engine.
It happens because Murano aims not only to provide the pure catalog 
capabilities, but also to manage the lifecycle of the deployed
applications: provide ways to handle external and internal events, maintain the 
applications' state, report usage statistics etc - all of this usually requires 
workflows, and these workflows have to be aware about the applications' data 
structure and interdependencies. That's where the idea of Murano's workflow 
engine came from.

However, it turned out to be overcomplicated and having some potential overlaps 
with existing OpenStack projects (you probably saw a very long discussions here 
about it) - and we are now working hard to fix this, by establishing a clean 
separation between plain catalog functionality of Murano and the 
workflow-related processes: some of them should go to different projects, some 
will remain in Murano but in more unified and clear manner. We'll have a couple 
of design sessions on this as well - at the "cross-project workshop" ([2], [3])
- feel free to join as well, if you are interested.

Speaking about the data storage for Murano, currently we look forward to the 
Glance Artifact Repository: we expect murano application packages (being 
composed out of Heat templates, workflows, binary files and other stuff) to be 
stored as composite multi-part artifacts in Glance. Each part of this artifact 
will be an "entry-point" for some action is some OpenStack service (like you 
said: boot sources for Nova, templates for Heat etc), while the workflow which 
coordinates this various services and tells them which part of artifact to boot 
from will be run as the higher-level layer service.
Hope this answer your questions. If you have more to ask, please feel free to 
join our weekly meeting in IRC ([4]) - the nearest one is today (Tuesday), at 
17:00 UTC

Thanks!


[1] 
http://junodesignsummit.sched.org/event/b0e1f0cbefffa942e276f1add9f85d03#.U2h8JF6nDWU
[2] 
http://junodesignsummit.sched.org/event/b7f067ff055ff7db9c92867f3febe1d9#.U2iAd16nDWU
[3] 
http://junodesignsummit.sched.org/event/556d10915a1a0a2f1aee3ba286826b60#.U2iAeF6nDWU
[4] https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
--
Regards,
Alexander Tivelkov


On Tue, May 6, 2014 at 9:37 AM, Tripp, Travis S  wrote:
> Hi Angus,
>
>> This seems neat, but also seems to have some overlap with glance's 
>> new catalog and some of the things Murano are doing. Have you had a look at 
>> those efforts?
>
> Thanks! We have been keeping an eye on the Glance work and the Murano work, 
> and your email reminded me to catch back up on both of them. I think in both 
> cases that the Graffiti concepts are complementary. However, strictly 
> speaking from a bird's eye view on application categorization, there is some 
> reconciliation to work out on that aspect.
>
> Regarding the Glance artifact repository, this looks like a nice revamp of 
> its concepts. Most of it seems to be very related to handling artifacts, 
> dependencies, versions, and relationships associated with packaging in a 
> generic way so that external services can use it in a variety of ways. There 
> is one feature that was discusse

[openstack-dev] [sahara] Nominate Trevor McKay for sahara-core

[Sergey Lukjanov]

Hey folks,

I'd like to nominate Trevor McKay (tmckay) for sahara-core.

He is among the top reviewers of Sahara subprojects. Trevor is working
on Sahara full time since summer 2013 and is very familiar with
current codebase. His code contributions and reviews have demonstrated
a good knowledge of Sahara internals. Trevor has a valuable knowledge
of EDP part and Hadoop itself. He's working on both bugs and new
features implementation.

Some links:

http://stackalytics.com/report/contribution/sahara-group/30
http://stackalytics.com/report/contribution/sahara-group/90
http://stackalytics.com/report/contribution/sahara-group/180
https://review.openstack.org/#/q/owner:tmckay+sahara+AND+-status:abandoned,n,z
https://launchpad.net/~tmckay

Sahara cores, please, reply with +1/0/-1 votes.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

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

Re: [openstack-dev] [Horizon] Project list with turned-on policy in Keystone

[Yaguang Tang]

Roman,

It's not fully supported, right now domain, project ,user management isn't
supported within admin user or domain user,  but you can login in with
domain user
and operate as a normal user.


2014-05-06 16:23 GMT+08:00 Roman Bodnarchuk :

>  Hello,
>
> Does this mean that there is no real support for non-default domains in
> Horizon?
>
> Thanks,
> Roman
>
>
> On 5/5/2014 2:30 PM, Yaguang Tang wrote:
>
> I think this is an common requirement for users who want to keystone v3. I
> filed a blueprint for it
> https://blueprints.launchpad.net/horizon/+spec/domain-based-rbac.
>
>
> 2014-04-24 23:30 GMT+08:00 Roman Bodnarchuk  >:
>
>>  Hello,
>>
>> As far as I can tell, Horizon uses python-openstack-auth to authenticate
>> users.  In the same time, openstack_auth.KeystoneBackend.authenticate
>> method generates only project scoped tokens.
>>
>> After enabling policy checks in Keystone, I tried to view a list of all
>> projects on Admin panel and got "*Error: *Unauthorized: Unable to
>> retrieve project list." on dashboard and the next in Keystone log:
>>
>> enforce identity:list_projects: {'project_id':
>> u'80d91944f5af4c53ad5df4e386376e08', 'group_ids': [], 'user_id':
>> u'ed14fd91122b47d2a6f575499ed0c4bb', 'roles': [u'admin']}
>> ...
>> WARNING keystone.common.wsgi [-] You are not authorized to perform the
>> requested action, identity:list_projects.
>>
>> This is expected, since user's token is scoped to project, and no access
>> to domain-wide resources should be allowed.
>>
>> How to work-around this?  Is it possible to use policy checks on Keystone
>> side while working with Horizon?
>>
>> I am using stable/icehouse and Keystone API v3.
>>
>> Thanks,
>> Roman
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
>  Tang Yaguang
>
>  Canonical Ltd. | www.ubuntu.com | www.canonical.com
> Mobile:  +86 152 1094 6968
> gpg key: 0x187F664F
>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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
>
>


-- 
Tang Yaguang

Canonical Ltd. | www.ubuntu.com | www.canonical.com
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Brandon Logan]

Outside the room where most of the Neutron meetings have been.  B103 I
believe.

On Mon, 2014-05-12 at 20:52 +, Samuel Bercovici wrote:
> During our brief meeting today, we tentatively scheduled to meet today
> at 5:30 PM. 
> Is this still on?
> Where should we meet?
> 
> Regards, 
>  -Sam.
> 
> On May 12, 2014, at 1:10 PM, "Adam Harwell"
>  wrote:
> 
> 
> > Some of us are at a table towards the back by the B3b door (and a
> > large restrooms sign).
> > 
> > On May 12, 2014 12:24 PM, Adam Harwell 
> > wrote:
> > 
> > Yeah, I guess we'll try to catch people after this session (lunch
> > officially starts at 12:45 apparently).
> > 
> > On May 12, 2014 11:48 AM, Eugene Nikanorov 
> > wrote:
> > 
> > I'm going to attend the next nw session @b103, we can meet in
> > between. Im in b103 too.
> > 
> > 
> > ___
> > 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] [Fuel] useful deployment related talks

[Allamaraju, Subbu]

We should perhaps clarify that these etherpads are about deployment/operations 
of OpenStack discussed under 
https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Ops, and not Fuel.

Subbu

On May 12, 2014, at 2:33 PM, Vladimir Kuklin  wrote:

> Guys
> 
> It would be awesome if we shared links on useful talks/meetups that can be 
> related to FUEL and deployment/operations of Openstack. 
> 
> These are for setting optimal config options and upgrades:
> 
> https://etherpad.openstack.org/p/juno-summit-ops-upgradesdeployment
> https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
> ___
> 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] [Neutron][LBaaS] Meetup?

[Samuel Bercovici]

During our brief meeting today, we tentatively scheduled to meet today at 5:30 
PM.
Is this still on?
Where should we meet?

Regards,
 -Sam.

On May 12, 2014, at 1:10 PM, "Adam Harwell" 
mailto:adam.harw...@rackspace.com>> wrote:


Some of us are at a table towards the back by the B3b door (and a large 
restrooms sign).

On May 12, 2014 12:24 PM, Adam Harwell 
mailto:adam.harw...@rackspace.com>> wrote:

Yeah, I guess we'll try to catch people after this session (lunch officially 
starts at 12:45 apparently).

On May 12, 2014 11:48 AM, Eugene Nikanorov 
mailto:enikano...@mirantis.com>> wrote:

I'm going to attend the next nw session @b103, we can meet in between. Im in 
b103 too.

___
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] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Joe Mcbride]

Hi all,
Members of the Designate project are in room 203 at the Neutron pod. Look
forward to meeting you all.

On 5/9/14, 9:17 AM, "Hayes, Graham"  wrote:

>Hi,
>
>It looks like us 'none ATC' folk will have access to the project pods -
>so should we nail down a time on Monday?
>
>It looks like the 16:30 onwards is the most popular choice - will we say
>16:30 on Monday in the Neutron pod?
>
>Thanks,
>
>Graham
>
>On Tue, 2014-05-06 at 17:45 +, Veiga, Anthony wrote:
>Hi,
>
>The only issue I would see with the pod is that not all of us are ATCs,
>so we may or may not have access to that area (I am open to correction on
>that point - in fact I hope someone does ;) )
>
>
>I¹ll second this.  I have an interest in attending and assisting here,
>but I don¹t have ATC status yet (though I¹m an active contributor
>technically, just not via code.)
>
>
>
>
>I could see it fitting in with our design session, but maybe if we meet
>on the Monday to do some initial hashing out as well, I think that would
>be good.
>
>I am around for the morning, and later on in the afternoon on Monday, if
>that suits.
>
>Graham
>
>On Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:
>
>
>I have just updated my etherpad [1] with some proposed times.  Not
>knowing much about the venue, I could only propose the "pod area" as a
>the location.
>
>I also updated the designate session etherpad [2] per your suggestion.
> If there is time during the Designate sessions to include this in the
>discussion then that may work out well.
>
>Thanks,
>Carl
>
>[1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
>[2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession
>
>On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride
>mailto:jmcbr...@rackspace.com>> wrote:
>>> On 4/29/14, 3:09 PM, "Carl Baldwin"
>>>mailto:c...@ecbaldwin.net>> wrote:>>>I feel this is
>>>an important subject to discuss because the end result>>will be a
>>>better cloud user experience overall.  The design summit>>could be a
>>>great time to bring together interested parties from>>Neutron, Nova,
>>>and Designate to discuss the integration that I propose>>in these
>>>blueprints.>> Do you have a time/location planned for these
>>>discussions? If not, we may> have some time in one of the Designate
>>>sessions.  The priorities and> details for our design session will be
>>>pulled from> 
>>>https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you
>>>are> interested in joining us, can you add your proposed blueprints in
>>>the> format noted there?>> Thanks,> joe>>>
>>>___> OpenStack-dev mailing
>>>list> 
>>>OpenStack-dev@lists.openstack.org>>rg>> 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
>
>
>___
>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] [designate] Windows problem with install workshop VM

[Joe Mcbride]

The following command created a virtual box compatible files:
>tar xopft designate-workshop_virtualbox.box

I was then able to import the box.ovf file and run it in VirtualBox
('vagrant/vagrant' for user/pass).  Can someone with access to a windows
machine give it a run? We can consider this for those running windows.


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

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

[Yaguang Tang]

Tiwari,

Could you elaborate how to solve the issue by using unique role names ?
With domain model, services like nova have to be aware of domain admin user
and cloud admin user by roles.  domain admin
manage IAM resources and non-IAM resources by inheriting  roles to
projects, cloud admin have additional privilege to enable/disable
OpenStack services. But the "admin" role can be granted by a domain user to
its own  user. How nova api identity a user is real admin
 user that in admin domain?


2014-05-10 2:23 GMT+08:00 Tiwari, Arvind :

>  Hi All,
>
>
>
> Thanks for looking in to my proposal. Below are my comments and answers to
> questions which is based on “my personal opinion”.
>
>
>
> *Why domain hierarchy, why not project hierarchy? *Because project
> hierarchy is more impactful and need cross project changes.
>
>
>
> As per my understanding we all are trying to solve one business use
> problem, which is “how to support VPC or Reseller” model on OS based cloud
> deployment.  As per problem described in different proposals, it is purely
> a IAM use case, where different identities (users, admins, reseller ….) has
> different perception about the system/resources (IAM and non IAM) and they
> want ability to manage them.
>
>
>
> Keystone (OS IAM service) abstracts all the IAM complexity  from lower
> level services (Nova, Swift, cinder …) by providing unified integration
> model (auth token and verification by auth middleware). Lover level
> services trusts Keystone and allow access (for particular requests) to
> actual resource based on subject’s roles provided by keystone.
>
>
>
> Each service supports multi tenancy and tenancy mapping is establish by
> keystone through projects.  If hierarchy enforced at project level then we
> need to propagate the hierarchy info to all lower level services, where the
> hierarchy  info is not serving any good purpose but just used to map one
> tenant. Enforcing the hierarchy at project level is more impactful because
> all services have to change their implementation to consume the notion of
> hierarchy. Propagating project hierarchy to services would make sense if
> end resources (VMs, cinder volumes , swift resource ….) does obey the
> hierarchy based on projects, I think that is not the case.
>
>
>
> As per definition domains are container for projects, users and groups and
> maps well with a business entities (ProductionIT, SuperDevShop,
> WidgetMaster, SPI, reseller .). Using domain to establish hierarchy (as
> per my design) will abstract the complexity from lower level services.
> Services don’t have to worry about the domain hierarchy and we can retain
> the current integration (Keystone project <-> service Tenant ) model and no
> need to make big change in different service. Mostly one place change which
> is Keystone.
>
>
>
> *Services has to be domain aware*
>
>
>
> IMO services (Nova, Swift …) don’t have to be domain aware (Unless I am
> missing something) as they manage resources for keystone projects. Domain
> is IAM concept which used to scope IAM resources and not very useful for
> end services. I think what we are lacking is unique role (role name) per
> service, having unique role names for each service (IAM, Nova, Swift ….)
>  will resolve the problem mentioned below by  Yaguang Tang.
>
>
>
> Please let me know why services have to be domain aware?
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Arvind
>
>
>
> Note:
>
> IAM Resources – Users, groups, projects …
>
> Non IAM resources – VMs, Swift objects, …….
>
>
>
> *From:* Yaguang Tang [mailto:yaguang.t...@canonical.com]
> *Sent:* Friday, May 09, 2014 4:33 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> *Frittoli,*
>
>
>
> I think for other services we could achieve that by  modifying  the
> policy.json( add domain admin role and control what the cloud admin can do
> ) so that domain admin user is able to manage resources belong to
>
> users and projects in that domain.
>
>
>
> 2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) :
>
> *From:* Adam Young [mailto:ayo...@redhat.com]
> *Sent:* 09 May 2014 04:19
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
>
>  Hi All,
>
>
>
> Below is my proposal to address VPC use case using hierarchical
> administrative boundary. This topic is scheduled in Hierarchical
> Multitenancysession
>  of Atlanta design summit.
>
>
>
> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary
>
>
>
> Please take a look.
>
>
>
> Thanks,
>
> Arvind
>
>
>
>
>
>  ___
>
> OpenStack-dev mailing list
>
>
>
> OpenStack-dev@lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/op

Re: [openstack-dev] [nova] plan for moving to using oslo.db

[Roman Podoliaka]

Hi all,

Yes, once the oslo.db initial release is cut, we expect the migration
from using of its oslo-incubator version to a library one to be as
simple as following the steps you've mentioned. Though, we still need
to finish the setup of oslo.db repo (AFAIK, this is currently blocked
by the fact we don't run gate tests for oslo.db patches. Doug, Victor,
please correct me, if I'm wrong).

Thanks,
Roman

On Mon, May 5, 2014 at 7:47 AM, Matt Riedemann
 wrote:
> Just wanted to get some thoughts down while they are in my head this
> morning.
>
> Oslo DB is now a library [1].  I'm trying to figure out what the steps are
> to getting Nova to using that so we can rip out the sync'ed common db code.
>
> 1. Looks like it's not in global-requirements yet [2], so that's probably a
> first step.
>
> 2. We'll want to cut a sqlalchemy-migrate release once this patch is merged
> [3]. This moves a decent chunk of unique constraint patch code out of oslo
> and into sqlalchemy-migrate where it belongs so we can run unit tests with
> sqlite to drop unique constraints.
>
> 3. Rip this [4] out of oslo.db once migrate is updated and released.
>
> 4. Replace nova.openstack.common.db with oslo.db.
>
> 5. ???
>
> 6. Profit!
>
> Did I miss anything?
>
> [1] http://git.openstack.org/cgit/openstack/oslo.db/
> [2]
> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt
> [3] https://review.openstack.org/#/c/87773/
> [4] https://review.openstack.org/#/c/31016/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> ___
> 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] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron

[Susanne Balle]

I apologize if you received this email already 

Reminder that we plan to meet tomorrow

Tuesday May 13 at 2pm at the Neutron pod on level 3.

Susanne

We are setting up a meeting to discuss if it makes sense to separate the
advanced services (LBaaS, FW, VPNaaS) from Neutron into separate projects.
We want a healthy discussion around  the pros and cons of separating the
advanced services from Neutron and its short or long term feasibility.



The meeting is planned for:

*Tuesday May 13th at 2pm in the Neutron pod.*


On Mon, May 12, 2014 at 12:40 PM, Balle, Susanne wrote:

> Reminder that we plan to meet tomorrow
>
> Tuesday May 13 at 2pm at the Neutron pod on level 3.
>
> Susanne
>
> Sent from my iPhone
>
> On May 7, 2014, at 7:45 AM, "Susanne Balle"  sleipnir...@gmail.com>> wrote:
>
> Hi Advanced Services/LBaaS Stackers,
>
> We are setting up a meeting to discuss if it makes sense to separate the
> advanced services (LBaaS, FW, VPNaaS) from Neutron into separate projects.
> We want a healthy discussion around  the pros and cons of separating the
> advanced services from Neutron and its short or long term feasibility.
>
> The meeting is planned for:
> Tuesday May 13th at 2pm in the Neutron pod.
>
> There will be a designated pod for each of the official programs at:
> https://wiki.openstack.org/wiki/Programs
> Some programs share a pod. There will be a map at the center of the space,
> as well as signage up to help find the relevant pod.
>
> Based on discussions with Rackspace, Mirantis, and others it is clear that
> the advanced services (i.e. LBaaS) in Neutron are not getting the attention
> and the support to move forward and create a first in class load-balancer
> service; from a service provider or operator's perspective. We currently
> have a lot of momentum and energy behind the LBaaS effort but are being
> told that the focus for Neutron is bug fixing given the instability in
> Neutron itself. While the latter is totally understandable, as a high
> priority for Neutron it leaves the advanced services out in the cold with
> no way to make progress in developing features that are needed to support
> the many companies that rely on LBaaS for large scale deployments.
>
> The current Neutron LB API and feature set meet minimum requirements for
> small-medium private cloud deployments, but does not meet the needs of
> larger, provider (or operator) deployments that include hundreds if not
> thousands of load balancers and multiple domain users (discrete customer
> organizations). The OpenStack LBaaS community looked at requirements and
> noted that the following operator-focused requirements are currently
> missing:
>
> • Scalability
> • SSL Certificate management – for an operator-based service, SSL
> certificate management is a much more important function that is currently
> not addressed in the current API or blueprint
> • Metrics Collection – a very limited set of metrics are currently
> provided by the current API.
> • Separate admin API for NOC and support operations
> • Minimal downtime when migrating to newer versions
> • Ability to migrate load balancers (SW to HW, etc.)
> • Resiliency functions like HA and failover
> • Operator-based load balancer health checks
> • Support multiple, simultaneous drivers.
>
> We have had great discussions on the LBaaS mailing list and on IRC about
> all the things we want to do, the new APIs, the User use cases,
> requirements and priorities, the operator requirements for LBaaS, etc. and
> I am at this point wondering if Neutron LBaaS as a sub-project of Neutron
> can fulfill our requirements.
>
> I would like this group to discuss the pros and cons of separating the
> advanced services, including LB, VPN, and FW, out of Neutron and allow for
> each of the three currently existing advanced services to become
> stand-alone projects or one standalone project.
>
> This should be done under the following assumptions:
>
> • Keep backwards compatibility with the current Neutron LBaaS
> plugin/driver API (to some point) so that existing drivers/plug-ins
> continues to work for people who have already invested in Neutron LBaaS
>
> • Migration strategy.
>
> We have a precedence in OpenStack of splitting up services that are
> becoming too big or where sub-services deserve to become an entity of its
> own e.g. baremetal Nova and Ironic, Nova-network and Neutron,
> nova-scheduler is being worked into the Gantt project, etc.
>
> At a high-level I see the following steps/blueprints needing to be carried
> out:
>
> • Identify and create a library similar in concept to OpenStack
> core that contains the common components pieces needed by the advanced
> services in order to minimize code duplication between the advanced
> services and Neutron. This library should be consumable by external
> projects and will allow for cleaner code reuse by not o

Re: [openstack-dev] Gerrit shortcut question

[Jay Pipes]

On Mon, May 12, 2014 at 2:23 PM, Lowery, Mathew  wrote:

> Thanks Sean and Jay.
>
> The point in asking was to understand if I was doing something wrong
> because the behavior I wanted wasn't in Gerrit UI. Both of you suggested
> git review -d which makes sense.
>
> No worries at all, Mathew, it's a very common need and common question.

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

[openstack-dev] [Fuel] useful deployment related talks

[Vladimir Kuklin]

Guys

It would be awesome if we shared links on useful talks/meetups that can be
related to FUEL and deployment/operations of Openstack.

These are for setting optimal config options and upgrades:

https://etherpad.openstack.org/p/juno-summit-ops-upgradesdeployment
https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gerrit shortcut question

[Lowery, Mathew]

Thanks Sean and Jay.

The point in asking was to understand if I was doing something wrong
because the behavior I wanted wasn't in Gerrit UI. Both of you suggested
git review -d which makes sense.

Thanks again.

On 5/12/14, 1:10 PM, "Sean Dague"  wrote:

>On 05/12/2014 01:03 PM, Lowery, Mathew wrote:
>> Gerrit supplies the following "shortcuts" for any change (in the "new
>> screen", there's a Download drop down in the top right or for the "old
>> screen", it's just under the Patch Set heading):
>> 
>> Checkoutgit fetch https://review.openstack.org/openstack/trove
>> refs/changes/09/88709/11 && git checkout FETCH_HEAD
>> Cherry-Pickgit fetch https://review.openstack.org/openstack/trove
>> refs/changes/09/88709/11 && git cherry-pick FETCH_HEAD
>> Format-Patchgit fetch https://review.openstack.org/openstack/trove
>> refs/changes/09/88709/11 && git format-patch -1 --stdout FETCH_HEAD
>> Pullgit pull https://review.openstack.org/openstack/trove
>> refs/changes/09/88709/11
>> Patch-File629016b.diff.base64 | 629016b.diff.zip
>> 
>> I have questions regarding these shortcuts, specifically in the context
>> of Gerrit dependencies (i.e. one Gerrit change depends on another Gerrit
>> change) Let's say my ultimate goal is to get the patch set including its
>> dependencies and apply those to the latest master because I want to do
>> some manual testing. Below is my understanding of the existing options
>> (feel free to correct any incorrect statements):
>> 
>>   * Checkout grabs the original sequence of commits as they were at
>> submit time. In other words, all the parent commits are the same as
>> when the patch set was submitted. The master and the parent
>> dependencies could have all advanced or changed.
>>   * Cherry-pick applies the diff introduced by the named patch set
>> alone. Parent dependencies are not involved.\
>>   * Format-patch: I don't know when to use this.
>>   * Pull: By default this will merge the two branches (and create a
>> merge commit). However, I have pulls configured to always rebase.
>> When the pull does a rebase, the patch set and its dependencies do
>> not appear as the most recent commits which I find not ideal.
>>   * Patch-File: Isn't this a portable cherry-pick? How does it relate to
>> format-patch?
>> 
>> So that summarizes my understanding of the current shortcuts.
>> 
>> What (I think) I want (that is not provided) is this:
>> 
>> git fetch https://review.openstack.org/openstack/trove
>> refs/changes/09/88709/11 && git checkout FETCH_HEAD && git
>> fetch https://review.openstack.org/openstack/trove master && git rebase
>> FETCH_HEAD
>> 
>> In other words, fetch the patch set with dependencies then check it out
>> (detached head). Fetch the latest master then rebase the patch set (and
>> dependencies) on the latest master. End result: latest master with patch
>> set and all dependencies as the most recent commits.
>> 
>> Am I missing something fundamental or would this be a useful shortcut to
>> have?
>
>Is there a reason you aren't just using git-review for this?
>
>git review -d 88709 && git rebase master
>
>   -Sean
>
>-- 
>Sean Dague
>http://dague.net
>


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

Re: [openstack-dev] Gerrit shortcut question

[Sean Dague]

On 05/12/2014 01:03 PM, Lowery, Mathew wrote:
> Gerrit supplies the following "shortcuts" for any change (in the "new
> screen", there's a Download drop down in the top right or for the "old
> screen", it's just under the Patch Set heading):
> 
> Checkoutgit fetch https://review.openstack.org/openstack/trove
> refs/changes/09/88709/11 && git checkout FETCH_HEAD
> Cherry-Pickgit fetch https://review.openstack.org/openstack/trove
> refs/changes/09/88709/11 && git cherry-pick FETCH_HEAD
> Format-Patchgit fetch https://review.openstack.org/openstack/trove
> refs/changes/09/88709/11 && git format-patch -1 --stdout FETCH_HEAD
> Pullgit pull https://review.openstack.org/openstack/trove
> refs/changes/09/88709/11
> Patch-File629016b.diff.base64 | 629016b.diff.zip
> 
> I have questions regarding these shortcuts, specifically in the context
> of Gerrit dependencies (i.e. one Gerrit change depends on another Gerrit
> change) Let's say my ultimate goal is to get the patch set including its
> dependencies and apply those to the latest master because I want to do
> some manual testing. Below is my understanding of the existing options
> (feel free to correct any incorrect statements):
> 
>   * Checkout grabs the original sequence of commits as they were at
> submit time. In other words, all the parent commits are the same as
> when the patch set was submitted. The master and the parent
> dependencies could have all advanced or changed.
>   * Cherry-pick applies the diff introduced by the named patch set
> alone. Parent dependencies are not involved.\
>   * Format-patch: I don't know when to use this.
>   * Pull: By default this will merge the two branches (and create a
> merge commit). However, I have pulls configured to always rebase.
> When the pull does a rebase, the patch set and its dependencies do
> not appear as the most recent commits which I find not ideal.
>   * Patch-File: Isn't this a portable cherry-pick? How does it relate to
> format-patch?
> 
> So that summarizes my understanding of the current shortcuts.
> 
> What (I think) I want (that is not provided) is this:
> 
> git fetch https://review.openstack.org/openstack/trove
> refs/changes/09/88709/11 && git checkout FETCH_HEAD && git
> fetch https://review.openstack.org/openstack/trove master && git rebase
> FETCH_HEAD
> 
> In other words, fetch the patch set with dependencies then check it out
> (detached head). Fetch the latest master then rebase the patch set (and
> dependencies) on the latest master. End result: latest master with patch
> set and all dependencies as the most recent commits.
> 
> Am I missing something fundamental or would this be a useful shortcut to
> have?

Is there a reason you aren't just using git-review for this?

git review -d 88709 && git rebase master

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gerrit shortcut question

[Jay Pipes]

You can do that with:

git fetch --all
git review -d 
git rebase master

Best,
-jay


On Mon, May 12, 2014 at 1:03 PM, Lowery, Mathew  wrote:

>  Gerrit supplies the following "shortcuts" for any change (in the "new
> screen", there's a Download drop down in the top right or for the "old
> screen", it's just under the Patch Set heading):
>
>  Checkout git fetch 
> https://review.openstack.org/openstack/troverefs/changes/09/88709/11 && git 
> checkout FETCH_HEAD
> Cherry-Pick git fetch 
> https://review.openstack.org/openstack/troverefs/changes/09/88709/11 && git 
> cherry-pick FETCH_HEAD
> Format-Patch git fetch 
> https://review.openstack.org/openstack/troverefs/changes/09/88709/11 && git 
> format-patch -1 --stdout FETCH_HEAD
> Pull git pull 
> https://review.openstack.org/openstack/troverefs/changes/09/88709/11
> Patch-File 629016b.diff.base64 | 629016b.diff.zip
>
>  I have questions regarding these shortcuts, specifically in the context
> of Gerrit dependencies (i.e. one Gerrit change depends on another Gerrit
> change) Let's say my ultimate goal is to get the patch set including its
> dependencies and apply those to the latest master because I want to do some
> manual testing. Below is my understanding of the existing options (feel
> free to correct any incorrect statements):
>
>- Checkout grabs the original sequence of commits as they were at
>submit time. In other words, all the parent commits are the same as when
>the patch set was submitted. The master and the parent dependencies could
>have all advanced or changed.
>- Cherry-pick applies the diff introduced by the named patch set
>alone. Parent dependencies are not involved.\
>- Format-patch: I don't know when to use this.
>- Pull: By default this will merge the two branches (and create a
>merge commit). However, I have pulls configured to always rebase. When the
>pull does a rebase, the patch set and its dependencies do not appear as the
>most recent commits which I find not ideal.
>- Patch-File: Isn't this a portable cherry-pick? How does it relate to
>format-patch?
>
> So that summarizes my understanding of the current shortcuts.
>
>  What (I think) I want (that is not provided) is this:
>
>  git fetch 
> https://review.openstack.org/openstack/troverefs/changes/09/88709/11 &&
> git checkout FETCH_HEAD && git fetch
> https://review.openstack.org/openstack/trove master && git rebase
> FETCH_HEAD
>
>  In other words, fetch the patch set with dependencies then check it out
> (detached head). Fetch the latest master then rebase the patch set (and
> dependencies) on the latest master. End result: latest master with patch
> set and all dependencies as the most recent commits.
>
>  Am I missing something fundamental or would this be a useful shortcut to
> have?
>
>  Thanks for any help,
> Mat
>
> ___
> 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] [nova] plan for moving to using oslo.db

[Victor Sergeyev]

Hello Matt.

Thanks a lot for your working on this!
In my opinion, these steps are correct. Please see a few minor notes below.

1 - Yes, you right, oslo.db is not in global-requirements now. Blueprint
``Split openstack.common.db code into a separate oslo.db library `` [1]  is
not completed at the moment. Please see ``work items`` section in [1] for
the actual bp state

2,3 - Looks good to me :)

4 - If you want, you test it locally even without oslo.db in
global-requirements. You can replace nova.openstack.common.db with oslo.db
on  and run unittests. This will help us to find and fix potential issues
with porting to oslo.db (if any).
If you will have any issues or questions, please feel free to ping me or
Roman Podoliaka via irc or e-mail.

5 - ???

6 - Profit!

[1] https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib

Thanks,
Victor


On Mon, May 5, 2014 at 5:47 PM, Matt Riedemann
wrote:

> Just wanted to get some thoughts down while they are in my head this
> morning.
>
> Oslo DB is now a library [1].  I'm trying to figure out what the steps are
> to getting Nova to using that so we can rip out the sync'ed common db code.
>
> 1. Looks like it's not in global-requirements yet [2], so that's probably
> a first step.
>
> 2. We'll want to cut a sqlalchemy-migrate release once this patch is
> merged [3]. This moves a decent chunk of unique constraint patch code out
> of oslo and into sqlalchemy-migrate where it belongs so we can run unit
> tests with sqlite to drop unique constraints.
>
> 3. Rip this [4] out of oslo.db once migrate is updated and released.
>
> 4. Replace nova.openstack.common.db with oslo.db.
>
> 5. ???
>
> 6. Profit!
>
> Did I miss anything?
>
> [1] http://git.openstack.org/cgit/openstack/oslo.db/
> [2] http://git.openstack.org/cgit/openstack/requirements/tree/
> global-requirements.txt
> [3] https://review.openstack.org/#/c/87773/
> [4] https://review.openstack.org/#/c/31016/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> ___
> 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] [Neutron] Changing subnet tenant_id

[Fawad Khaliq]

Hi Andre,

You encountered a normal API operation. The error raised is a valid return
as you cannot modify the tenant_id. For the API documentation, tenant_id
field is there for Administrator purpose when an Admin wants to update
subnet for a particular tenant (using tenant_id to refer to the instance of
a subnet of tenant for whom the tenant_id is specified).

Thanks,
Fawad Khaliq
(m) +1 408.966.2214


On Mon, May 12, 2014 at 9:54 AM, André Aranha wrote:

> Hi,
>
> I was checking networks in Neutron and in the API 
> (http://api.openstack.org/api-ref-networking-v2.html) it is said that one can 
> update a subnet tenant-id. I tried and raised an error: "NeutronError": 
> "Cannot update read-only attribute tenant_id". Is it really supported to 
> change a subnet tenant-id or is it a bug?
>
> Thank you,
> Andre Aranha
>
>
> ___
> 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] [Neutron] Blueprint - Auto-associate floating IP

[Salvatore Orlando]

You can try and reach out the original assignee (sweston) on IRC.
I haven't heard from him in a while; if he's not actively working on this
topic anymore I think it's ok for you to take over.

Feel free to get in touch with me (salv-orlando) on IRC for discussing
implementation alternatives.

Salvatore


On 12 May 2014 19:26, Simeon D Monov  wrote:

> Hello,
>
> I see there were some discussions and proposed implementations on
> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ipblueprint
>  (including a mail thread
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019489.html)
> but there was no activity on it in the past 6 months.
>
> I would like to work on this blueprint if nobody else is working on it.
>
> Regards,
> Simeon Monov
>
> ___
> 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] [Fuel][HA][RabbitMQ] Rabbitmq-related HA issues

[Vladimir Kuklin]

Guys, I suggest that we meet at Mirantis booth as it is in the same hall
with lunch
12 мая 2014 г. 13:02 пользователь "Andrew Woodward" 
написал:

> Correct. Openstack HA
> On May 12, 2014 12:43 PM, "Mike Scherbakov" 
> wrote:
>
>> A little note - it's going to be about OpenStack HA issues, not about
>> Fuel master node HA, right?
>> On May 12, 2014 8:37 PM, "Vladimir Kuklin"  wrote:
>>
>>> Fuelers,
>>>
>>>
>>> We are going to discuss rabbit/kombu related HA issues today. I suggest
>>> we do this at 1pm today in Hall B2 during lunch. Feel free to provide
>>> alternative suggestions if you have any objections. Also bring in anyone
>>> who may be of help.
>>>
>>> List of problems and bugs is here:
>>> https://etherpad.openstack.org/p/fuel-ha-rabbitmq
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 45bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>> ___
>>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Blueprint - Auto-associate floating IP

[Simeon D Monov]

Hello,

I see there were some discussions and proposed implementations on 
https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip 
blueprint (including a mail thread 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019489.html
) but there was no activity on it in the past 6 months.

I would like to work on this blueprint if nobody else is working on it.

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

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

Some of us are at a table towards the back by the B3b door (and a large 
restrooms sign).

On May 12, 2014 12:24 PM, Adam Harwell  wrote:

Yeah, I guess we'll try to catch people after this session (lunch officially 
starts at 12:45 apparently).

On May 12, 2014 11:48 AM, Eugene Nikanorov  wrote:

I'm going to attend the next nw session @b103, we can meet in between. Im in 
b103 too.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Gerrit shortcut question

[Lowery, Mathew]

Gerrit supplies the following "shortcuts" for any change (in the "new screen", 
there's a Download drop down in the top right or for the "old screen", it's 
just under the Patch Set heading):

Checkout git fetch https://review.openstack.org/openstack/trove 
refs/changes/09/88709/11 && git checkout FETCH_HEAD
Cherry-Pick git fetch https://review.openstack.org/openstack/trove 
refs/changes/09/88709/11 && git cherry-pick FETCH_HEAD
Format-Patch git fetch https://review.openstack.org/openstack/trove 
refs/changes/09/88709/11 && git format-patch -1 --stdout FETCH_HEAD
Pull git pull https://review.openstack.org/openstack/trove 
refs/changes/09/88709/11
Patch-File 629016b.diff.base64 | 629016b.diff.zip

I have questions regarding these shortcuts, specifically in the context of 
Gerrit dependencies (i.e. one Gerrit change depends on another Gerrit change) 
Let's say my ultimate goal is to get the patch set including its dependencies 
and apply those to the latest master because I want to do some manual testing. 
Below is my understanding of the existing options (feel free to correct any 
incorrect statements):

  *   Checkout grabs the original sequence of commits as they were at submit 
time. In other words, all the parent commits are the same as when the patch set 
was submitted. The master and the parent dependencies could have all advanced 
or changed.
  *   Cherry-pick applies the diff introduced by the named patch set alone. 
Parent dependencies are not involved.\
  *   Format-patch: I don't know when to use this.
  *   Pull: By default this will merge the two branches (and create a merge 
commit). However, I have pulls configured to always rebase. When the pull does 
a rebase, the patch set and its dependencies do not appear as the most recent 
commits which I find not ideal.
  *   Patch-File: Isn't this a portable cherry-pick? How does it relate to 
format-patch?

So that summarizes my understanding of the current shortcuts.

What (I think) I want (that is not provided) is this:

git fetch https://review.openstack.org/openstack/trove refs/changes/09/88709/11 
&& git checkout FETCH_HEAD && git fetch 
https://review.openstack.org/openstack/trove master && git rebase FETCH_HEAD

In other words, fetch the patch set with dependencies then check it out 
(detached head). Fetch the latest master then rebase the patch set (and 
dependencies) on the latest master. End result: latest master with patch set 
and all dependencies as the most recent commits.

Am I missing something fundamental or would this be a useful shortcut to have?

Thanks for any help,
Mat
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][HA][RabbitMQ] Rabbitmq-related HA issues

[Andrew Woodward]

Correct. Openstack HA
On May 12, 2014 12:43 PM, "Mike Scherbakov" 
wrote:

> A little note - it's going to be about OpenStack HA issues, not about Fuel
> master node HA, right?
> On May 12, 2014 8:37 PM, "Vladimir Kuklin"  wrote:
>
>> Fuelers,
>>
>>
>> We are going to discuss rabbit/kombu related HA issues today. I suggest
>> we do this at 1pm today in Hall B2 during lunch. Feel free to provide
>> alternative suggestions if you have any objections. Also bring in anyone
>> who may be of help.
>>
>> List of problems and bugs is here:
>> https://etherpad.openstack.org/p/fuel-ha-rabbitmq
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> ___
>> 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

[openstack-dev] [Neutron] Changing subnet tenant_id

[André Aranha]

Hi,

I was checking networks in Neutron and in the API
(http://api.openstack.org/api-ref-networking-v2.html) it is said that
one can update a subnet tenant-id. I tried and raised an error:
"NeutronError": "Cannot update read-only attribute tenant_id". Is it
really supported to change a subnet tenant-id or is it a bug?

Thank you,
Andre Aranha
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] custom gerrit dashboard - per project review inbox zero

[Sean Dague]

On 05/11/2014 10:26 AM, Mark McLoughlin wrote:
> On Fri, 2014-05-09 at 08:20 -0400, Sean Dague wrote:
>> Based on some of my blog posts on gerrit queries, I've built and gotten
>> integrated a custom inbox zero dashboard which is per project in gerrit.
>>
>> ex:
>> https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard
>>
>> (replace openstack/nova with the project of your choice).
>>
>> This provides 3 sections.
>>
>> = Needs Final +2 =
>>
>> This is code that has an existing +2, no negative code review feedback,
>> and positive jenkins score. So it's mergable if you provide the final +2.
>>
>> (Gerrit Query: status:open NOT label:Code-Review>=0,self
>> label:Verified>=1,jenkins NOT label:Code-Review<=-1 label:Code-Review>=2
>> NOT label:Workflow<=-1 limit:50 )
>>
>> = No negative feedback =
>>
>> Changes that have no negative code review feedback, and positive jenkins
>> score.
>>
>> (Gerrit Query: status:open NOT label:Code-Review>=0,self
>> label:Verified>=1,jenkins NOT label:Code-Review<=-1 NOT
>> label:Workflow<=-1 limit:50 )
>>
>> = Wayward changes =
>>
>> Changes that have no code review feedback at all (no one has looked at
>> it), a positive jenkins score, and are older than 2 days.
>>
>> (Gerrit Query: status:open label:Verified>=1,jenkins NOT
>> label:Workflow<=-1 NOT label:Code-Review<=2 age:2d)
>>
>>
>> In all cases it filters out patches that you've commented on in the most
>> recently revision. So as you vote on these things they will disappear
>> from your list.
>>
>> Hopefully people will find this dashboard also useful.
> 
> Nicely done. Any reason you've included the stable branches - i.e. not
> restricted it to branch:master ?

Because it hadn't quite occurred to me yet to filter it out. I think
that would be a good change. Joe also mentioned filtering out things you
own: NOT owner:self. Which I also think would be a good change.

The processing of changing these is currently a little odd because of
where they live in the gerrit meta data. I'm hoping we can get this into
a normal code review flow in the next couple of weeks and get these
changes in, as well making it easy to get people to add new additional
dashboards as well.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][HA][RabbitMQ] Rabbitmq-related HA issues

[Mike Scherbakov]

A little note - it's going to be about OpenStack HA issues, not about Fuel
master node HA, right?
On May 12, 2014 8:37 PM, "Vladimir Kuklin"  wrote:

> Fuelers,
>
>
> We are going to discuss rabbit/kombu related HA issues today. I suggest we
> do this at 1pm today in Hall B2 during lunch. Feel free to provide
> alternative suggestions if you have any objections. Also bring in anyone
> who may be of help.
>
> List of problems and bugs is here:
> https://etherpad.openstack.org/p/fuel-ha-rabbitmq
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> 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] [Fuel][HA][RabbitMQ] Rabbitmq-related HA issues

[Vladimir Kuklin]

Fuelers,


We are going to discuss rabbit/kombu related HA issues today. I suggest we
do this at 1pm today in Hall B2 during lunch. Feel free to provide
alternative suggestions if you have any objections. Also bring in anyone
who may be of help.

List of problems and bugs is here:
https://etherpad.openstack.org/p/fuel-ha-rabbitmq


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

Yeah, I guess we'll try to catch people after this session (lunch officially 
starts at 12:45 apparently).

On May 12, 2014 11:48 AM, Eugene Nikanorov  wrote:

I'm going to attend the next nw session @b103, we can meet in between. Im in 
b103 too.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Eugene Nikanorov]

I'm going to attend the next nw session @b103, we can meet in between. Im
in b103 too.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

I'm not sure if there's anything super important today that everyone is 
attending. I'm in the Future of Neutron panel right now, but would people want 
to meet up after that? Maybe over some lunch, since I think most of my team 
missed breakfast? :)
After that would probably work too, again provided there aren't any other super 
important panels we'd be missing.

  --Adam

On May 12, 2014 11:32 AM, Eugene Nikanorov  wrote:

Hi,

what time are you suggesting?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Sandhya Dasu (sadasu)]

Developer Lounge at 1 PM today!!

Thanks,
Sandhya

On 5/12/14 10:23 AM, "Irena Berezovsky"  wrote:

>Hi all,
>Where are we going to meet for this meeting at 1:00 pm today?
>
>-Original Message-
>From: Robert Li (baoli) [mailto:ba...@cisco.com]
>Sent: Friday, May 09, 2014 10:52 PM
>To: Sandhya Dasu (sadasu); Brent Eagles; Steve Gordon
>Cc: Dan Smith; OpenStack Development Mailing List (not for usage
>questions); John Garbutt; Russell Bryant; yunhong-jiang; Itzik Brown;
>Yongli He; Jay Pipes; Irena Berezovsky
>Subject: Re: Informal meeting before SR-IOV summit presentation
>
>the program pods area should be open.
>
>On 5/9/14, 3:33 PM, "Sandhya Dasu (sadasu)"  wrote:
>
>>I have no idea, how to pick a location.
>>Should we meet at the Cisco booth at 1pm and then take it from there?
>>
>>Any other ideas?
>>
>>Thanks,
>>sandhya
>>
>>On 5/9/14 3:17 PM, "Brent Eagles"  wrote:
>>
>>>On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:
 Thanks for all your replies.

 Thanks for the great inputs on how to frame the discussion in the
etherpad  so it becomes easier for people to get on board. We will
add author indent  to track the source of the changes. Will work on
cleaning that up.

 Regarding the session itself, as you probably know, there was an
attempt  in Icehouse to get the sr-iov work going. We found that the
time allotted  for the session was not sufficient to get to all the
use cases and discuss  alternate views.

 This time around we want to be better prepared and so would like to
keep  only a couple of open times for the actual session. Hence, the
request for  the early meeting.

 How does Monday 1pm sound?

 Thanks,
 Sandhya
>>>
>>>That time is good with me.
>>>
>>>Cheers,
>>>
>>>Brent
>>>
>>
>


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

Re: [openstack-dev] [Neutron][LBaaS] Meetup?

[Eugene Nikanorov]

Hi,

what time are you suggesting?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Meetup?

[Adam Harwell]

When / where are we planning to meet up? If I recall from the last IRC meeting, 
we were planning to get together at least unofficially to start discussing 
stuff as soon as sometime Monday (today). Are the pods already open and 
available, or is that not until later?

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

Re: [openstack-dev] [nova] Dynamic scheduling

[Jay Lau]

For those who are interested in "dynamic scheduling", you can go to IBM
booth today (5.12) from 10:45 to  12:45, we will have a simple demo there.

There will also be a design session "Future of Gantt APIs and interfaces"
which include "run time policy for OpenStack" at Friday, May 16 10:50am -
11:30am (
http://junodesignsummit.sched.org/event/36c19ae807a02ef7015ab042fd4541e6#.U3DNpChpdeM
)

The google doc related to "run time policy" is here:
https://docs.google.com/document/d/1DMsnGxQ3P-OwZCF3uxaUeEFaKX8LqUqmmgQ_7EVK7Y8/edit?usp=sharing

Thanks!


2014-04-12 1:00 GMT+08:00 Tim Bell :

>
>
> > -Original Message-
> > From: Andrew Laski [mailto:andrew.la...@rackspace.com]
> > Sent: 11 April 2014 16:38
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [nova] Dynamic scheduling
> >
> > On 04/10/14 at 11:33pm, Oleg Gelbukh wrote:
> > >Andrew,
> > >
> ...
> >
> > In my opinion what's being proposed doesn't seem to fit cleanly into any
> existing service, so perhaps it could start as a standalone
> > entity.
> > Then once there's something that can be used and demoed a proper place
> might suggest itself, or it might make sense to keep it
> > separate.
> >
>
> I strongly support no auto scaling. Heat looks after this and is a user
> facing activity since it needs to know what to do when a new VM is created
> and how to set it up.
>
> A dynamic scheduling 'service' would work on an operator infrastructure
> layer performing VM relocation according to the service provider needs
> (balance between optimisation, thrashing, acceptable downtime). It should
> be performed within the SLA expectations of the VM.
>
> The dynamic scheduling is 'OpenStack Tetris', trying to ensure a
> consistent packing policy of VMs on resources based on the policy for the
> service class.
>
> Tim
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

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

Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability Testing and plan for Summit session

[Liz Blanchard]

Hi Travis,

Thanks very much for passing this information along. It would be great to sync 
up on the changes and concepts that you’ve worked on regarding the launch 
instance workflow. I will plan to be at the majority of the Graffiti session to 
learn more and then I will be headed to a session that we are having around 
User Experience as a whole and how we move forward as a team @ 2:50 on Tuesday. 
If you’d like to chat more specifically about the launch instance workflow 
design, please feel free to attend the Usability Testing session we are doing 
where we will talk through our proposed design and give your thoughts! If you 
don’t have a chance to attend this, definitely try to track down either Jacki 
or I this week to chat informally :)

Best,
Liz
On May 12, 2014, at 12:34 AM, Tripp, Travis S  wrote:

> Hello Horizon team,
>  
> We’ve been working on some concepts that we’d like to see be incorporated in 
> the launch instance workflow new UI or existing UI.  We have a related design 
> session at the summit and would love to get feedback! We’ll be showing some 
> early prototyping work that we’ve been doing.
>  
> http://junodesignsummit.sched.org/event/61439e8187a25985473ea53cc078#.U2-w3ldLpT5
>  
> https://etherpad.openstack.org/p/juno-summit-graffiti
>  
> Thanks,
> Travis
>  
> From: Liz Blanchard [mailto:lsure...@redhat.com] 
> Sent: Friday, May 09, 2014 3:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Horizon] [UX] Summary of Horizon Usability 
> Testing and plan for Summit session
>  
> One last addition, I promise :)
>  
> Another item that we would like to tackle in Juno based on the Usability 
> Testing results is to make some improvements to the way we give our users 
> inline help in forms. I’ve put together a doc that includes our current 
> solution and some suggestions for improvements. If there is time, we will be 
> discussing this during the session as well:
> http://people.redhat.com/~lsurette/OpenStack/ImprovementstoInlineHelpinHorizon.pdf
>  
> See you all next week!
>  
> Liz
> On May 7, 2014, at 3:50 PM, Liz Blanchard  wrote:
> 
> 
> Hi All,
>  
> Another topic on the agenda for this session is to talk a bit about creating 
> some guidelines around Error messaging in Horizon, and hopefully this will 
> trickle through other components as needed. I’ve put together some initial 
> thoughts around this topic and want to get it out to the list so folks might 
> have some time to take a look before discussing at the session. If you have 
> any feedback, feel free to respond before summit and I can update this doc.
>  
> http://people.redhat.com/~lsurette/OpenStack/ImprovingtheUXofMessageswithinHorizon.pdf
>  
> Thanks,
> Liz
> On Apr 30, 2014, at 2:50 PM, Jacki Bauer  wrote:
> 
> 
> Hi everyone,
> As Liz mentioned, we did some testing and one of the big findings was that 
> the Launch Instance form had some usability issues. I took a stab at mocking 
> up a launch instance process that addresses some of these issues. You can 
> read the usability findings here.
>  
> So, I know some of you will ask about work that is already being done around 
> improving the launch instance form - here and here.  That work is represented 
> here too! I took what I felt to be what was best about the current form and 
> best about the new work, addressed the usability issues, and tried to come up 
> with something that wasn’t too different from either of these.
>  
> If you are interested in any of the design thinking/reasoning behind the 
> mockups, go ahead and keep reading below, otherwise, just take a look at the 
> attachment.  Feedback is welcome!
>  
> Cheers,
> Jacki
>  
> Why I did things the way I did:
> I used a multi-step form for a few reasons. 1-The Horizon people are 
> interested in wizard patterns that could be used for launching instances and 
> other step by step workflows. 2-The current launch instance divides the 
> config options into tabs, but users often didn’t notice the tabs until they 
> tried to launch the instance and got an error. The “*” indicating required 
> fields on each tab confused users as well. Since all but one tab contained 
> required fields, the tabs didn’t do anything to reduce the number of clicks a 
> user had to make in order to complete the form.
> A best practice for wizards is to never reveal specific steps to the user if 
> the number or names of those steps can change.  So, I settled on four steps. 
> Some users might not want to visit all these steps, and this is maybe a flaw. 
> Maybe we can think about a way to allow users to skip steps.
> I decided to stack all fields vertically with labels to the left. I did this 
> because I wanted the layout of form fields to be consistent throughout. This 
> layout is very readable and pretty standard. It saves vertical space too.
> I changed the network selection to checkboxes. Users thought the drag and 
> drop style control was inconsistent

Re: [openstack-dev] [Neutron] Database migrations meeting at summit

[Henry Gessau]

Update: The meeting time is changed to accommodate some people with very
full schedules.

New Time: Tuesday morning, 09:50


On Mon, May 12, at 8:05 am, Anna Kamyshnikova  wrote:

> Hi!
> 
> It is great idea to organize such meeting. Unfortunately I can't participate
> in it as I'm not going to summit, but members of my team Oleg Bondarev and
> Eugene Nikanorov will be there. They should be up to speed on my current
> developments. I hope that they will be able to come to meeting and discuss
> problems that I faced. 
> 
> Also I added commit messages to my test change requests for unconditional
> migrations topic. It will help to understand what options I tried to
> research in them.
> 
> Regards,
> Ann
> 
> 
> On Thu, May 8, 2014 at 11:57 PM, Henry Gessau  > wrote:
> 
> Several developers are working on different aspects of Neutron DB 
> migration.
> I thought it would be good to have a meeting at the summit where we can
> discuss the issues and come closer to converging on a solution.
> 
> I was thinking maybe a time on Tuesday or Thursday afternoon would work. I
> have created an etherpad [1] where I have tried to accumulate the emails,
> bugs, bps and code proposals. If you are interested in meeting please add
> your name to the etherpad.
> 
> Also please add any missing notes/references to the etherpad.
> 
> [1] https://etherpad.openstack.org/p/neutron-db-migrations
> 
> 


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

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Irena Berezovsky]

Hi all,
Where are we going to meet for this meeting at 1:00 pm today?

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Friday, May 09, 2014 10:52 PM
To: Sandhya Dasu (sadasu); Brent Eagles; Steve Gordon
Cc: Dan Smith; OpenStack Development Mailing List (not for usage questions); 
John Garbutt; Russell Bryant; yunhong-jiang; Itzik Brown; Yongli He; Jay Pipes; 
Irena Berezovsky
Subject: Re: Informal meeting before SR-IOV summit presentation

the program pods area should be open.

On 5/9/14, 3:33 PM, "Sandhya Dasu (sadasu)"  wrote:

>I have no idea, how to pick a location.
>Should we meet at the Cisco booth at 1pm and then take it from there?
>
>Any other ideas?
>
>Thanks,
>sandhya
>
>On 5/9/14 3:17 PM, "Brent Eagles"  wrote:
>
>>On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:
>>> Thanks for all your replies.
>>>
>>> Thanks for the great inputs on how to frame the discussion in the 
>>>etherpad  so it becomes easier for people to get on board. We will 
>>>add author indent  to track the source of the changes. Will work on 
>>>cleaning that up.
>>>
>>> Regarding the session itself, as you probably know, there was an 
>>>attempt  in Icehouse to get the sr-iov work going. We found that the 
>>>time allotted  for the session was not sufficient to get to all the 
>>>use cases and discuss  alternate views.
>>>
>>> This time around we want to be better prepared and so would like to 
>>>keep  only a couple of open times for the actual session. Hence, the 
>>>request for  the early meeting.
>>>
>>> How does Monday 1pm sound?
>>>
>>> Thanks,
>>> Sandhya
>>
>>That time is good with me.
>>
>>Cheers,
>>
>>Brent
>>
>


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

[openstack-dev] [MagnetoDB] Lists as data types in MagnetoDB

[Illia Khudoshyn]

Hi openstackers,

It looks like we should support lists of values in MagnetoDB, along with
sets and single values.

Initially MagnetoDB API was designed compatible with Amazon DynamoDB API.
Currently it supports strings, decimals, blobs and sets of the above as
supported data types. I believe that lists are even more useful collections
than sets so for me it sounds reasonable for us to have it supported. This
should not require much effort for us since Cassandra as the only supported
backend for now supports lists out of the box.

Below is the link to the blueprint:
https://blueprints.launchpad.net/magnetodb/+spec/list-as-data-type

Please, share your thoughts

-- 

Best regards,

Illia Khudoshyn,
Software Engineer, Mirantis, Inc.



38, Lenina ave. Kharkov, Ukraine

www.mirantis.com 

www.mirantis.ru



Skype: gluke_work

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

[openstack-dev] [Cinder] Qcow2 support for cinder-backup

[Zhangleiqiang (Trump)]

Hi, all:

I have planned to add the support to create qcow2 format file in NFS 
driver ([1]). From the comment of Eric Harney, I know that cinder-backup 
service currently assumes the volume is raw-formatted, and enable creating 
qcow2 in NFS driver will break backups of NFS volumes . 

After reading the code of backup service, I find we can first mount the 
qcow2 volume as a NBD device and then pass the NBD device as the "source 
volume_file" to backup service. Similar method of mounting qcow2 as NBD device 
has already used in Nova now. I think we can add it to NFS driver for backup, 
and it can be used for GlusterFS too.

Any advice? Is there something I have not expected?

[1] https://review.openstack.org/#/c/92011/

--
zhangleiqiang (Trump)

Best Regards



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

Re: [openstack-dev] [oslo][db] oslo.db repository review request

[Victor Stinner]

Hi,

Le vendredi 18 avril 2014, 17:28:04 Victor Sergeyev a écrit :
> During Icehouse release cycle our team has been working on splitting of
> openstack common db code into a separate library blueprint [1]. At the
> moment the issues, mentioned in this bp and [2] are solved and we are
> moving forward to graduation of oslo.db. You can find the new oslo.db code
> at [3]

There was a discussion recently about the "oslo" namespace. Sorry, but I don't 
remember the decision.

Should the new module be called "oslo.db" or "olsodb"?

(I would prefer "oslodb", it avoids issues with the "oslo" package.)

Victor (Stinner aka haypo)

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

Re: [openstack-dev] [Neutron] Database migrations meeting at summit

[Anna Kamyshnikova]

Hi!

It is great idea to organize such meeting. Unfortunately I can't
participate in it as I'm not going to summit, but members of my team Oleg
Bondarev and Eugene Nikanorov will be there. They should be up to speed on
my current developments. I hope that they will be able to come to meeting
and discuss problems that I faced.

Also I added commit messages to my test change requests for unconditional
migrations topic. It will help to understand what options I tried to
research in them.

Regards,
Ann


On Thu, May 8, 2014 at 11:57 PM, Henry Gessau  wrote:

> Several developers are working on different aspects of Neutron DB
> migration.
> I thought it would be good to have a meeting at the summit where we can
> discuss the issues and come closer to converging on a solution.
>
> I was thinking maybe a time on Tuesday or Thursday afternoon would work. I
> have created an etherpad [1] where I have tried to accumulate the emails,
> bugs, bps and code proposals. If you are interested in meeting please add
> your name to the etherpad.
>
> Also please add any missing notes/references to the etherpad.
>
> [1] https://etherpad.openstack.org/p/neutron-db-migrations
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Docker] Master node bootstrapping issues

[Aleksandr Didenko]

> 4) do lrzipping as weak as possible during the development phase and
lrzip it strongly only when we do release

We create lrzip archive with compression level "2" (from 1-9 range, default
is 7). So we don't have much potential for improvement here. Here are some
tests:

== Bare metal 12 cpus, 32 G RAM ==
level 1 decompression total time: 00:00:27.70
level 2 decompression total time: 00:00:29.64

== Virtual server 1 cpu, 1G RAM ==
level 1 decompression total time: 00:05:17.12
level 2 decompression total time: 00:05:22.86


I did some further research on this matter, increasing RAM to 4G did not
help much as well:

== Virtual server 1 cpu, 4G RAM ==
level 1 decompression total time: 00:05:08.70
level 2 decompression total time: 00:05:12.57

So it looks like 'lrzuntar' command itself causes this problem on a weak
hardware, because it uses "lrzcat | tar" which works very fast if we have
enough memory. If we extract archive in two separate steps (lrzip -d && tar
-xf) instead of single "lrzuntar", then they take only ~1m30s summary
(comparing to 5+ minutes with single lrzuntar command). Here are some test
results for lrzip+tar commands:

== Bare metal 12 cpus, 32 G RAM ==
level 2 decompression total time: 00:00:50.12

== Virtual server 1 cpu, 1G RAM ==
level 2 decompression total time: 00:01:35.95

So "lrzuntar" works faster on a powerful hardware, lrzip+tar works faster
on a weak hardware (like VMs).

I suggest to switch to lrzip+tar.



On Sat, May 10, 2014 at 8:01 PM, Dmitry Borodaenko  wrote:

> FWIW 1GB works fine for me on my laptop, I run the master setup manually.
> So I'm against increasing RAM requirement, we have better things to spend
> that RAM on.
> On May 10, 2014 1:37 AM, "Mike Scherbakov" 
> wrote:
>
>> It is not related to RAM or CPU. I run installation on my Mac with 1Gb of
>> RAM for master node, and experience the following:
>>
>>- yes, it needs time to bootstrap admin node
>>- As soon as I have message that master node is installed, I
>>immediately open 10.20.0.2:8000 and try to generate diag snapshot.
>>And it is failed.
>>- If I wait a few more minutes, and try again - it is passed.
>>
>> It actually seems to me that we simply still do not have
>> https://bugs.launchpad.net/fuel/+bug/1315865 fixed, I'll add more
>> details there as well as logs.
>>
>> When I checked logs, I saw:
>>
>>- for about a minute, astute was not able to connect to MQ. It means
>>it is still started before MQ is ready?
>>- shotgun -c /tmp/dump_config >> /var/log/dump.log 2>&1 && cat
>>/var/www/nailgun/dump/last returned 1
>>
>> When I tried to run diag_snapshot for a second time, the command above
>> succeeded with 0 return code.
>>
>> So it obviously needs further debugging and in my opinion even if we need
>> to increase VCPU or RAM, then no more than 2 VCPU / 2 Gb.
>>
>> Vladimir, as you and Matt were changing the code which should run
>> containers in a certain order, I'm looking forward to hear from both of you
>> suggestions on where and how we should hack it.
>>
>> Thanks,
>>
>>
>> On Sat, May 10, 2014 at 1:04 AM, Vladimir Kuklin wrote:
>>
>>> Hi all
>>>
>>> We are still experiencing some issues with master node bootstrapping
>>> after moving to container-based installation.
>>>
>>> First of all, these issues are related to our system tests. We have
>>> rather small nodes running as master node - only 1 GB of RAM and 1 virtual
>>> CPU. As we are using strongly lrzipped archive, this seems quite not enough
>>> and leads to timeouts during deployment of the master node.
>>>
>>> I have several suggestions:
>>>
>>> 1) Increase amount of RAM for  master node to at least 8 Gigabytes (or
>>> do some pci virtual memory hotplug during master node bootstrapping) and
>>> add additional vCPU for the master node.
>>> 2) Run system tests with non-containerized environment (env variable
>>> PRODUCTION=prod set)
>>> 3) Split our system tests in that way not allowing more than 2 master
>>> nodes to bootstrap simulteneously on the single hardware node.
>>> 4) do lrzipping as weak as possible during the development phase and
>>> lrzip it strongly only when we do release
>>> 5) increase bootstrap timeout for the master node in system tests
>>>
>>>
>>> Any input would be appreciated.
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 45bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailm

Re: [openstack-dev] turbo-hipster question: where to get nova.sql

[Peng GP Gu]

Hi!
   Thanks for replying.

   For creating a nova database to dump, I hope I can take the scale of
your sql file
   as a references, so can you tell me the number of instances and the base
schema
   version in your sql file ?  Thanks!

   I'm currently testing the nova migrations under db2, I thought this
could be added
   to turbo-hipster as a plugin.

Peng Gu

Michael Still  wrote on 05/09/2014 11:39:08 AM:

> From: Michael Still 
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Cc: Zhu ZZ Zhu/China/IBM@IBMCN
> Date: 05/09/2014 11:38 AM
> Subject: Re: [openstack-dev] turbo-hipster question: where to get
nova.sql
>
> Hi! Thanks for taking a look at turbo hipster!
>
> Our nova.sql files are quite large (hundreds of megabytes), so we
> don't check them into source control. They're also dumps of production
> databases with some anonymization, so we're not licensed to distribute
> them. Therefore, I think you're going to have to either create or find
> a nova database to dump to create your own nova.sql.
>
> Alternatively, is what you're testing something we could add to the
> turbo hipster we run?
>
> Michael
>
> On Fri, May 9, 2014 at 1:56 AM, Peng GP Gu  wrote:
> >  Hi,
> >
> >  I recently ran turbo-hipster to test nova db migrations, but I can't
find
> > nova.sql in the dataset cloned from github.
> >
> >  Can anyone tell me where to get nova.sql?
> >
> >  Thanks!
> >
> >  Peng Gu
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Rackspace Australia
>
> ___
> 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] Heat SoftwareConfig and SoftwareDevelopment

[LIU Casper A]

Hello dear Heat Developers,

I am Casper Liu from Alcatel-Lucent. I am doing a project based on 
Heat(Icehouse), and have questions about Heat SoftwareConfig and 
SoftwareDevelopment resources.

Your reply would be highly appreciated!
We really anticipate your support and help.

The key point of our project is to execute “heat stack-update” to update a 
stack with a number of VMs, and this “heat stack-update” will trigger a 
specified script to be executed on a specified VM instance(this VM already has 
the specified script) of the stack, and there should be no reboot/rebuild of 
any VM of the stack. If possible we would like to use SoftwareConfig to do 
this, for it is modularized and easy to manage, but cfn tool should also be OK.

Take our project as example, we have one stack which has 4 VMs (we can name 
them as VM1, VM2, VM3 and VM4), there is an need to let Heat template to 
execute one script(we have coded this Python script.) on VM1 when I execute 
"heat stack-update -f  -p " each time.
VM1 can be associated with SoftwareConfig and SoftwareDevelopment resources.
VM1 can NOT be rebooted or rebuilt during execution of "heat stack-update".

My question is:

(1) Could you advise a solution based on Heat for our project scenario?
(2) If a SoftwareDevelopment is set as "UPDATE" in “actions” field of template 
and associated with VM1 and SoftwareConfig and when "heat stack-update" 
happens, can the VM1 execute SoftwareConfig without reboot?
(3) If SoftwareConfig can be execute successfully for VM1, then what 
packages/tools should be installed in VM instance?
Such as hook-script.py ( 
http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/software-config/elements/heat-config-script/install.d/hook-script.py
 (http://git.openstack.org/cgit/opensta...) ), is this a must for 
SoftwareDevelopment?
(4) Is my software version(icehouse) proper to support SoftwareDevelopment and 
SoftwareConfig?

Below is the version of my Openstack pakages:

root@heatorch:~# pip freeze
... heat==2014.1.dev58.g5896354
python-ceilometerclient==1.0.8
python-cinderclient==1.0.7
python-debian==0.1.21ubuntu1
python-heatclient==0.2.6
python-keystoneclient==0.4.2
python-neutronclient==2.3.3
python-novaclient==2.15.0
python-swiftclient==1.8.0
python-troveclient==1.0.3
...

SoftwareDeployment introduction is as below:
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::Software

Your reply would be highly appreciated!

Thanks a lot!

Regards,
Casper


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

[openstack-dev] [TripleO] Haproxy configuration options

[Dmitriy Shulyak]

Adding haproxy (or keepalived with lvs for load balancing) will require
binding haproxy and openstack services on different sockets.
Afaik there is 3 approaches that tripleo could go with.

Consider configuration with 2 controllers:

haproxy:
nodes:
-   name: controller0
ip: 192.0.2.20
-   name: controller1
ip: 192.0.2.21

1. Binding haproxy on virtual ip and standard ports

haproxy:
services:
-   name: horizon
proxy_ip: 192.0.2.22 (virtual ip)
port: 80
proxy_port: 80
-   name: neutron
proxy_ip: 192.0.2.22 (virtual ip)
proxy_port: 9696
port: 9696

Pros:
- No additional modifications in elements is required
HA-Proxy version 1.4.24 2013/06/17
What was the reason this approach was dropped?

2. Haproxy listening on standard ports, services on non-standard

haproxy:
services:
-   name: horizon
proxy_ip: 192.0.2.22 (virtual ip)
port: 8080
proxy_port: 80
-   name: neutron
proxy_ip: 192.0.2.22 (virtual ip)
proxy_port: 9696
port: 9797

Pros:
- No changes will be required to init-keystone part of workflow
- Proxied services will be accessible on accustomed ports
- No changes to configs where services ports need to be hardcoded, for
example in nova.conf https://review.openstack.org/#/c/92550/

Cons:
- Config files should be changed to add possibility of ports configuration

3. haproxy on non-standard ports, with services on standard

haproxy:
services:
-   name: horizon
proxy_ip: 192.0.2.22 (virtual ip)
port: 8080
proxy_port: 80
-   name: neutron
proxy_ip: 192.0.2.22 (virtual ip)
proxy_port: 9797
port: 9696

Notice that i changed only port for neutron, main endpoint for horizon
should listen on default http or https ports.

Basicly it is opposite to 2 approach. I would prefer to go with 2, cause it
requires only minor refactoring.

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