date:20160727


Thanks Matt, a very correct and precise assessment on the usage in Nova.

I, however, wanted to point out one thing for the audience -- the v2
Image schemas are discoverable and assert the purpose of setting
operator defined and in most cases operator used protected properties.
This is when the api v2 was designed was considered, having a flat
namespace with schematic validation on the properties that makes it
richer experience for advanced usage. The downside, of course, if what
one sees when having relatively straightforward calls that have similar
assumptions with those of the v1 api.

http://developer.openstack.org/api-ref-image-v2.html#image-schemas-v2


On 7/27/16 4:44 PM, Matt Riedemann wrote:
> On 7/20/2016 7:01 PM, Nikhil Komawar wrote:
>
>> Thanks Matt. The bug looked very descriptive so, I commented my thoughts
>>
>> there https://bugs.launchpad.net/python-glanceclient/+bug/1596602
>>
>>
>>
>> On 7/20/16 4:18 PM, Matt Riedemann wrote:
>>
>>> On 7/18/2016 4:41 AM, Erno Kuvaja wrote:
>>>
 On Mon, Jul 18, 2016 at 5:19 AM, Nikhil Komawar

  wrote:

> Thanks Matt. I've scheduled for a release of the client this week.
>
>
>
> On 7/16/16 4:09 AM, Matt Riedemann wrote:
>
>> This is more of a heads up than anything.
>>
>>
>>
>> Our internal CI is running Tempest with images that don't have
>>
>> kernel_id or ramdisk_id properties set.
>>
>>
>>
>> We're running from master so nova defaults to use_glance_v1=False.
>>
>>
>>
>> Because of this:
>>
>>
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/compute/api.py#L867-L868
>>
>>
>>
>>
>>
>>
>>
>> and this:
>>
>>
>>
>> https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/image/glance.py#L835
>>
>>
>>
>>
>>
>>
>>
>> The snapshot image properties get kernel_id and ramdisk_id set to
>> None
>>
>> since that's what the glance v2 schema requires.
>>
>>
>>
>> However, python-glanceclient has it's own outdated copy of the schema
>>
>> which doesn't allow null values for those properties, see bug:
>>
>>
>>
>> https://bugs.launchpad.net/python-glanceclient/+bug/1596602
>>
>>
>>
>> We don't hit this in the community CI because the image that Tempest
>>
>> uses from devstack has the kernel_id and ramdisk_id properties set:
>>
>>
>>
>> http://logs.openstack.org/52/335152/1/check/gate-tempest-dsvm-neutron-src-python-glanceclient/d393db9/logs/devstacklog.txt.gz#_2016-06-28_18_40_12_429
>>
>>
>>
>>
>>
>>
>>
>> But for anyone else upgrading to Newton that has images without those
>>
>> properties set and doesn't have use_glance_v1=True in nova.conf is
>>
>> going to be broken.
>>
>>
>>
>> Since we really want to get people off glance v1 and move to
>>
>> deprecation in Ocata, we need to get this merged and released:
>>
>>
>>
>> https://review.openstack.org/#/c/335152/
>>
>>
>>
>> And bump the minimum required python-glanceclient in
>>
>> global-requirements for Newton.
>>
>>
>>
>> I'm not really sure why python-glanceclient even has it's own copy of
>>
>> the image schema, that seems redundant and error prone given the
>>
>> glance API already validates that, but it's kind of beside the point
>>
>> right now.
>>
>>
>>
>
>
> --
>
>
>
> Thanks,
>
> Nikhil
>
>
>
>
>
> __
>
>
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe:
>
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


 Hi Matt,



 Something has broken on the way if that shipped schema actually affect

 your operation. That should be used _only_ when the client is called

 without connection to the Glance API (for example in a case you have

 no env set and you call `glance help`), this is btw the reason why we

 have that schema shipped with the client.



 As soon as you execute a call that actually interacts with Glance API

 we should be pulling the schema from there. So if this is not the

 case, we've broken somewhere on the way. I'll try to find time to have

 a look.



 - Erno



 __



 OpenStack Development Mailing List (not for usage questions)

[openstack-dev] 回复： [neutron]dragonflow deployment incorrectness

2016-07-27 Thread kangjingting

Hi 
The reason why a namepspace be created while creating router is just because 
l3-agent is enabled. You can disable it as you want to.
At present, there is only dhcp app in dragonflow need packets from datapath, so 
you will observe controller related flows after you create vms in subnet where 
dhcp is enabled. 
BTW, if you want the all flows showed in br-int, including hidden flows, you 
can use command “ovs-appctl bridge/dump-flows br-int”
- 原始邮件 -
发件人："郑杰" 
收件人："openstack-dev" 
主题：[openstack-dev] [neutron]dragonflow deployment incorrectness
日期：2016年07月27日 14点46分

Hi ,everybody:

when I deploy DragonFlow, I start neutron-server
,df-local-controller and df-l3-router, but there still are router namespace
when I create routers ,I check ovs flow table ,there is no CONTROLLER actions
for ip traffic ,so I guess something wrong with my conf.

below are my neutron.conf and l3_agent.ini respectively

neutron.conf-

[DEFAULT]

dhcp_agent_notification = False

advertise_mtu = True

api_workers = 10

notify_nova_on_port_data_changes = True

notify_nova_on_port_status_changes = True

auth_strategy = keystone

allow_overlapping_ips = True

debug = True

service_plugins =

core_plugin = dragonflow.neutron.plugin.DFPlugin

transport_url = rabbit://stackrabbit:secret@172.16.18.127:5672/

logging_exception_prefix = %(color)s%(asctime)s.%(msecs)03d TRACE %(name)s
^[[01;35m%(instance)s^[[00m

logging_debug_format_suffix = ^[[00;33mfrom (pid=%(process)d) %(funcName)s
%(pathname)s:%(lineno)d^[[00m

logging_default_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s
%(name)s [^[[00;36m-%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m

logging_context_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s
%(name)s [^[[01;36m%(request_id)s ^[[00;36m%(user_name)s
%(project_id)s%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m

bind_host = 0.0.0.0

use_syslog = False

state_path = /opt/stack/data/neutron

[df]

pub_sub_driver = redis_db_pubsub_driver

enable_selective_topology_distribution = True

publisher_rate_limit_count = 1

publisher_rate_limit_timeout = 180

pub_sub_use_multiproc = False

enable_df_pub_sub = True

monitor_table_poll_time = 30

apps_list =
l2_app.L2App,l3_proactive_app.L3ProactiveApp,dhcp_app.DHCPApp,dnat_app.DNATApp,sg_app.SGApp,portsec_app.PortSecApp

integration_bridge = br-int

tunnel_type = geneve

local_ip = 172.16.18.127

nb_db_class = dragonflow.db.drivers.redis_db_driver.RedisDbDriver

remote_db_hosts = 172.16.18.127:4001

remote_db_port = 4001

remote_db_ip = 172.16.18.127

[df_l2_app]

l2_responder = True

[df_dnat_app]

ex_peer_patch_port = patch-int

int_peer_patch_port = patch-ex

external_network_bridge = br-ex

-l3_agent.ini
-

[DEFAULT]

l3_agent_manager = neutron.agent.l3_agent.L3NATAgentWithStateReport

external_network_bridge = br-ex

interface_driver = openvswitch

ovs_use_veth = False

debug = True

[AGENT]

root_helper_daemon = sudo /usr/bin/neutron-rootwrap-daemon
/etc/neutron/rootwrap.conf

root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf

--ovs-ofctl dump-flows
br-int---

NXST_FLOW reply (xid=0x4):

 cookie=0x0, duration=1710.883s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,in_port=19
actions=load:0x17->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)

 cookie=0x0, duration=1710.883s, table=0, n_packets=1268, n_bytes=53760,
idle_age=0, priority=100,in_port=13
actions=load:0x15->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)

 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,in_port=15
actions=load:0x1a->NXM_NX_REG6[],load:0x2->OXM_OF_METADATA[],resubmit(,1)

 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,in_port=20 
actions=load:0x1c->NXM_NX_REG6[],load:0x3->OXM_OF_METADATA[],resubmit(,1)

 cookie=0x0, duration=1710.876s, table=0, n_packets=3, n_bytes=126,
idle_age=643, priority=100,in_port=18
actions=load:0x1b->NXM_NX_REG6[],load:0x2->OXM_OF_METADATA[],resubmit(,1)

 cookie=0x0, duration=1710.883s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,tun_id=0x17
actions=load:0x17->NXM_NX_REG7[],load:0x3->OXM_OF_METADATA[],resubmit(,72)

 cookie=0x0, duration=1710.882s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,tun_id=0x15
actions=load:0x15->NXM_NX_REG7[],load:0x3->OXM_OF_METADATA[],resubmit(,72)

 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,tun_id=0x1a
actions=load:0x1a->NXM_NX_REG7[],load:0x2->OXM_OF_METADATA[],resubmit(,72)

 cookie=0x0, duration=1710.876s, table=0, n_packets=0, n_bytes=0,
idle_age=1710, priority=100,tun_id=0x1c

Re: [openstack-dev] [glance] [glare] Glance virtual midcycle recordings

Thanks Jeremy. The worse part is that we do have to share editable
collab links with the participants and they are out and visible.
Nevertheless, this is nice feature to use and can be useful in some
situations.

And, I was trying to be frivolous on the authorship colors but again
quite useful feature.


On 7/27/16 5:15 PM, Jeremy Stanley wrote:
> On 2016-07-27 13:08:35 -0400 (-0400), Nikhil Komawar wrote:
> [...]
>> There have been some noted instances where people either inadvertently
>> or otherwise have updated the etherpad, thus removing the text. Please
>> be considerate and watchful of your keyboard when keeping the etherpad open.
> Note that you can share read-only URLs to pads (checkbox under the
> "share and embed this pad" dropdown that looks like ), for people
> to use as a reference if they don't intend to make further
> modifications to its content.
>
>> But for the record, here's the content/links that can be accessed if you
>> are not a fan of the etherpad colors.
> [...]
>
> You can also hide the authorship colours in your browser (the
> "settings" dropdown that looks like a gear has a checkbox for that),
> if they're annoying.

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate

On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote:
> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
> Portland and won't be available for the next 2h or so.
> If you can have a look at it and merge it, that would be great.
> 
> References:
> [1]
> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
> [2] https://review.openstack.org/#/c/342604/1
> [3] https://bugs.launchpad.net/nova/+bug/1603979
> [4] logstash: http://goo.gl/79yFb9

I feel like we need to make a plan to more forward and that's going to require
some coordination.

The requirements team saw this coming in that nova's tests failed when 2.6.0
was added to the upper-constraints.txt.  We had a plan[1] but then failed to
execute.  The requirements team has a couple of TODOs from there but the
biggest one is to add actual cross-project gate checks so that we have *very
strong* signals that things will break.

So the state we're in is
oslo.context 2.6.0 is out and used in all projects that *do not* honor 
upper-constraints.txt
oslo.context 2.5.0 is being used by all projects that *do* honor 
upper-constraints.txt

The Path forward IMO is

a) Unblock oslo.context 2.6.0
- But leave upper-constraints.txt pointing to 2.5.0
- https://review.openstack.org/#/c/347608/
* We can test shims/fixes against this.
b) Identify projects that break with > 2.5.0
- Seems like this is (at least)
- Trove
- Nova
- Designate
- Others?
c) Add shims to them to work with 2.5.0 and newer
- Nova: https://review.openstack.org/#/c/342604/ and 
https://review.openstack.org/#/c/348057/
d) Bump u-c to point at "the latest"
e) Bump the minium in g-r to 2.6.0
f) Remove items from 'c'

Notes:
 - The requirements team will not be able to merge any change that bumps
   oslo.context in u-c until step 'd'.  The reality here is due to our
   tooling/gating that probably means that all u-c changes will be paused
 - As stated in my pre-amble we're working on testing to make this better.
 - We almost certainly need a corss-project session during the design summit to
   discuss the API boundry for the context and how projects are
   expected/allowed to use it.

Yours Tony.

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2016-07-15.log.html#t2016-07-15T03:42:24


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Select our project mascot/logo

2016-07-27 Thread Hongbin Lu

Hi all,

By aggregating all the inputs, it seems the most popular mascots are Waves, 
Kangaroo, Shark, and Moose. However, Kangaroo and Moose are taken by other 
teams, so we vote between Waves and Shark. If you have an accepted patch in any 
of the Magnum repo in Newton release cycle, you should receive an email with a 
link to vote. Please let me know if you haven't received the email. Have fun 
for voting!

Best regards,
Hongbin

> -Original Message-
> From: taget [mailto:qiaoliy...@gmail.com]
> Sent: July-27-16 2:51 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
> 
> 
> Does anyone know that Magnum is a brand of ice cream[1]?
> 
> I love it! can we use it, maybe it may bring some copyright issue, but
> I don't know..
> 
> [1] http://www.magnumicecream.com/us/en/home.html
> 
> On 2016年07月27日 13:47, hie...@vn.fujitsu.com wrote:
> > Hi all,
> >
> > I think Magnum mascot should be related to something that really big,
> can cover small things inside.
> > So, my 2$ idea is the yin-yang whale:
> > https://s-media-cache-
> ak0.pinimg.com/736x/90/1d/66/901d66b496d9b5470f2
> > 2981ab3c16da4.jpg
> >
> > Best regards,
> > Hieu LE.
> >
> > -Original Message-
> > From: Hongbin Lu [mailto:hongbin...@huawei.com]
> > Sent: Wednesday, July 27, 2016 9:26 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
> >
> > Dims,
> >
> > You are fast :). I believe OpenStack Foundation will coordinate in
> this case.
> >
> > Best regards,
> > Hongbin
> >
> >> -Original Message-
> >> From: Davanum Srinivas [mailto:dava...@gmail.com]
> >> Sent: July-26-16 9:56 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [Magnum] Select our project mascot/logo
> >>
> >> Hongbin,
> >>
> >> Moose is already taken by Oslo team (2 summits ago :)
> >>
> >> -- Dims
> >>
> >> On Tue, Jul 26, 2016 at 9:48 PM, Hongbin Lu 
> >> wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> Thanks for providing mascot ideas. As discussed at the team meeting,
> >>> below is the short list of popular mascots. I believe you will
> >> receive
> >>> a link to vote among them later.
> >>>
> >>> * Waves - http://www.123rf.com/photo_11649085_set-of-waves.html
> >>>
> >>> * Kangaroo - http://www.supercoloring.com/pages/red-kangaroo
> >>>
> >>> * Shark - http://www.logoground.com/logo.php?id=10554
> >>>
> >>> * Majestic moose -
> >>>
> >>
> https://images.indiegogo.com/file_attachments/1328366/files/201503260
> >> 8
> >>> 3908-Mooselaughing.jpg?1427384348
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Hongbin
> >>>
> >>>
> >>>
> >>> From: Watson, Stephen [mailto:stephen.wat...@intel.com]
> >>> Sent: July-26-16 12:09 PM
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> Subject: Re: [openstack-dev] [Magnum] Select our project
> mascot/logo
> >>>
> >>>
> >>>
> >>> +1 for kangaroo and stallion
> >>>
> >>>
> >>>
> >>> And my own suggestion even though it doesn’t fit the container or
> >> name
> >>> themes directly would be a St. Bernard because dogs and myths are
> >> cool:
> >>> http://mentalfloss.com/article/20908/why-are-st-bernards-always-
> >> depict
> >>> ed-barrels-around-their-necks
> >>>
> >>>
> >>>
> >>> -Stephen
> >>>
> >>>
> >>>
> >>> From: Hongbin Lu 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage
> >> questions)"
> >>> 
> >>> Date: Monday, July 25, 2016 at 5:54 PM
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [Magnum] Select our project mascot/logo
> >>>
> >>>
> >>>
> >>> Hi team,
> >>>
> >>>
> >>>
> >>> OpenStack want to promote individual projects by choosing a mascot
> >>> to represent the project. The idea is to create a family of logos
> >>> for OpenStack projects that are unique, yet immediately
> identifiable
> >>> as
> >> part of OpenStack.
> >>> OpenStack will be using these logos to promote each project on the
> >>> OpenStack website, at the Summit and in marketing materials.
> >>>
> >>>
> >>>
> >>> We can select our own mascot, and then OpenStack will have an
> >>> illustrator create the logo for us. The mascot can be anything from
> >>> the natural world—an animal, fish, plant, or natural feature such
> as
> >> a
> >>> mountain or waterfall. We need to select our top mascot candidates
> >>> by the first deadline (July 27, this Wednesday). There’s more info
> >>> on
> >> the website:
> >>> http://www.openstack.org/project-mascots
> >>>
> >>>
> >>>
> >>> Action Item: Everyone please let me know what is your favorite
> mascot.
> >>> You can either reply to this ML or discuss it in the next team
> >> meeting.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Hongbin
>

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

I think that would be true, if the container api was opinionated. for example, 
trying to map only a subset of the openstack config options to docker 
environment variables. This would make the containers specific to what your 
talking about. Which business rules to support, what hardware, etc.

But the api is a fairly small one. Its mostly a standardized way to pass config 
files in through docker volumes and get them to land in the right places in the 
container. You should be able to use any system you want (puppet, chef, jinja, 
shell scripts) to deal with the business logic and such, to generate the config 
files, then use the standard api contract to ensure that whatever way you 
launch the container, (puppet, chef, heat, docker run, kubelet, kubernetes, 
etc) it behaves the same. The way your generated config file specifies.

Kolla has provided many different variants of each of the containers (centos, 
ubuntu, etc), showing that api contract is pretty flexible.

A similar thing is going on with kolla-kubernetes.

Thanks,
Kevin


From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, July 27, 2016 3:12 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

Excerpts from Fox, Kevin M's message of 2016-07-27 21:51:15 +:
> Its a standard way of launching a given openstack service container with 
> specified config regardless if its backed with a redhat or ubuntu or source 
> based package set that the Operator can rely on having a standardized 
> interface to. distro packages don't grantee that kind of thing and don't want 
> to.
>
> To me, its an abstraction api kind of like nova is to kvm vs xen. the nova 
> user shouldn't have to care which backend is chosen.
>

You're not wrong, and I do believe there is programming happening to
these interfaces. However the surface area of the API you describe is
_WAY_ too big to justify the work to maintain it as a single entity.

This is really why deployment tooling is so diverse. Hardware, networks,
business rules, operating systems, licensing, regulatory constraints...
all of those are part of a real deployment, and trying to make an API
that allows covering all of those bases, versus just having a bunch of
specific-ish implementations, has so far resulted in acceptance of more
implementations nearly every time.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

2016-07-27 Thread Matthew Thode

On 07/27/2016 04:08 PM, Jeremy Stanley wrote:
> On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote:
>> We've started a period of self nomination in preparation for the
>> requirements project fully moving into project (as it's still under Doug
>> Hellmann).
>>
>> We are gathering the self nominations here before we vote next week.
>> https://etherpad.openstack.org/p/requirements-ptl-newton
>>
>> Nominees should also send an email to the openstack-dev list.
> 
> Have you determined whether your electorate are traditional project
> technical contributors (Gerrit owners of changes merged to the
> openstack/requirements repo over the past year) like most teams use,
> or is there a different focus and constituency for this team?
> 

We have talked about it somewhat, but just assumed it'd be those that
have submitted (and had merge) changes.  Doug's suggestion to include
the current 'wip' core team might be good, I know at least Tony and I
didn't know for sure if we'd be disqualified or not.

The term 'interim' for ptl I think is just because elections are coming
up soon.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Ok. :)

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 05:51 PM, Fox, Kevin M wrote:
> Its a standard way of launching a given openstack service container with 
> specified config regardless if its backed with a redhat or ubuntu or source 
> based package set that the Operator can rely on having a standardized 
> interface to. distro packages don't grantee that kind of thing and don't want 
> to.
>
> To me, its an abstraction api kind of like nova is to kvm vs xen. the nova 
> user shouldn't have to care which backend is chosen.

I can tell this conversation isn't going anywhere and we're not going to
agree, so let's just agree to disagree.

Best,
-jay

> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Wednesday, July 27, 2016 2:12 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is 
> getting Fuel CCP (docker/k8s) kicked off
>
> On 07/27/2016 04:42 PM, Ed Leafe wrote:
>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:
>>
>>> Its not an "end user" facing thing, but it is an "operator" facing thing.
>>
>> Well, the end user for Kolla is an operator, no?
>>
>>> I deploy kolla containers today on non kolla managed systems in production, 
>>> and rely on that api being consistent.
>>>
>>> I'm positive I'm not the only operator doing this either. This sounds like 
>>> a consumable api to me.
>>
>> I don’t think that an API has to be RESTful to be considered an interface 
>> for we should avoid duplication.
>
> Application *Programming* Interface. There's nothing that is being
> *programmed* or *called* in Kolla's image definitions.
>
> What Kolla is/has is not an API. As Stephen said, it's more of an
> Application Binary Interface (ABI). It's not really an ABI, though, in
> the traditional sense of the term that I'm used to.
>
> It's an agreed set of package bases, installation procedures/directories
> and configuration recipes for OpenStack and infrastructure components.
>
> I see no reason for the OpenStack community to standardize on those
> things, frankly. It's like asking RedHat and Canonical to agree to "just
> use RPM" as their package specification format. I wonder how that
> conversation would go.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

Excerpts from Jeremy Stanley's message of 2016-07-27 22:06:43 +:
> On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > However, we may have some folks on the core team who have not
> > contributed a patch, since it is far more common to do reviews than
> > to submit changes there (more and more of the changes are being
> > automated). So, we probably need to expand the traditional definition
> > to also include the existing core review team (members of
> > requirements-core [1]), just to be safe.
> [...]
> 
> Easy enough to do for a one-off, but might want to consider
> officially adding them as extra-ATCs in governance down the road to
> make that more explicit. Our existing tooling is already adapted to
> that solution as well (for example, the current i18n voters are
> _all_ recorded as extra-ATCs because we haven't implemented API
> calls to Zanata for integrating it into the normal roll generation
> process yet).

Sure, adding them to the extra-atcs list rather than adding custom rules
to the tools makes great sense.

> 
> However, implicitly adding core reviewers seems a little weird as
> they're officially appointed by the PTL and so allowing the
> incumbent PTL to appoint (or remove) specific voters before their
> pending reelection... well anyway, I guess it's balanced out by
> there being a lot more committers to that repo than core reviewers
> on it.

Yes, it is a bit unusual. I'd hate to have the core reviewers *not*
have a vote, though, since they're the ones doing the work in that
repo.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-27 Thread Clint Byrum

Excerpts from Fox, Kevin M's message of 2016-07-27 21:51:15 +:
> Its a standard way of launching a given openstack service container with 
> specified config regardless if its backed with a redhat or ubuntu or source 
> based package set that the Operator can rely on having a standardized 
> interface to. distro packages don't grantee that kind of thing and don't want 
> to.
> 
> To me, its an abstraction api kind of like nova is to kvm vs xen. the nova 
> user shouldn't have to care which backend is chosen.
> 

You're not wrong, and I do believe there is programming happening to
these interfaces. However the surface area of the API you describe is
_WAY_ too big to justify the work to maintain it as a single entity.

This is really why deployment tooling is so diverse. Hardware, networks,
business rules, operating systems, licensing, regulatory constraints...
all of those are part of a real deployment, and trying to make an API
that allows covering all of those bases, versus just having a bunch of
specific-ish implementations, has so far resulted in acceptance of more
implementations nearly every time.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
[...]
> However, we may have some folks on the core team who have not
> contributed a patch, since it is far more common to do reviews than
> to submit changes there (more and more of the changes are being
> automated). So, we probably need to expand the traditional definition
> to also include the existing core review team (members of
> requirements-core [1]), just to be safe.
[...]

Easy enough to do for a one-off, but might want to consider
officially adding them as extra-ATCs in governance down the road to
make that more explicit. Our existing tooling is already adapted to
that solution as well (for example, the current i18n voters are
_all_ recorded as extra-ATCs because we haven't implemented API
calls to Zanata for integrating it into the normal roll generation
process yet).

However, implicitly adding core reviewers seems a little weird as
they're officially appointed by the PTL and so allowing the
incumbent PTL to appoint (or remove) specific voters before their
pending reelection... well anyway, I guess it's balanced out by
there being a lot more committers to that repo than core reviewers
on it.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


On 07/27/2016 05:51 PM, Fox, Kevin M wrote:

Its a standard way of launching a given openstack service container with 
specified config regardless if its backed with a redhat or ubuntu or source 
based package set that the Operator can rely on having a standardized interface 
to. distro packages don't grantee that kind of thing and don't want to.

To me, its an abstraction api kind of like nova is to kvm vs xen. the nova user 
shouldn't have to care which backend is chosen.


I can tell this conversation isn't going anywhere and we're not going to 
agree, so let's just agree to disagree.


Best,
-jay



From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 2:12 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 04:42 PM, Ed Leafe wrote:

On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:


Its not an "end user" facing thing, but it is an "operator" facing thing.


Well, the end user for Kolla is an operator, no?


I deploy kolla containers today on non kolla managed systems in production, and 
rely on that api being consistent.

I'm positive I'm not the only operator doing this either. This sounds like a 
consumable api to me.


I don’t think that an API has to be RESTful to be considered an interface for 
we should avoid duplication.


Application *Programming* Interface. There's nothing that is being
*programmed* or *called* in Kolla's image definitions.

What Kolla is/has is not an API. As Stephen said, it's more of an
Application Binary Interface (ABI). It's not really an ABI, though, in
the traditional sense of the term that I'm used to.

It's an agreed set of package bases, installation procedures/directories
and configuration recipes for OpenStack and infrastructure components.

I see no reason for the OpenStack community to standardize on those
things, frankly. It's like asking RedHat and Canonical to agree to "just
use RPM" as their package specification format. I wonder how that
conversation would go.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

Excerpts from Jeremy Stanley's message of 2016-07-27 21:08:12 +:
> On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote:
> > We've started a period of self nomination in preparation for the
> > requirements project fully moving into project (as it's still under Doug
> > Hellmann).
> > 
> > We are gathering the self nominations here before we vote next week.
> > https://etherpad.openstack.org/p/requirements-ptl-newton
> > 
> > Nominees should also send an email to the openstack-dev list.
> 
> Have you determined whether your electorate are traditional project
> technical contributors (Gerrit owners of changes merged to the
> openstack/requirements repo over the past year) like most teams use,
> or is there a different focus and constituency for this team?

Excellent question.

I assumed that we would use the list of contributors to the
repositories managed by the team. At the moment I think that means
only the openstack/requirements repository.

However, we may have some folks on the core team who have not
contributed a patch, since it is far more common to do reviews than
to submit changes there (more and more of the changes are being
automated). So, we probably need to expand the traditional definition
to also include the existing core review team (members of
requirements-core [1]), just to be safe.

Does that include everyone we should?

Once we have consensus, I can document the decision in the wiki
under [2].

[1] https://review.openstack.org/#/admin/groups/131,members
[2] https://wiki.openstack.org/wiki/Requirements#Requirements_Team

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

2016-07-27 Thread Anita Kuno

On 07/27/2016 05:44 PM, Jeremy Stanley wrote:
> On 2016-07-27 17:38:49 -0400 (-0400), Anita Kuno wrote:
> [...]
>> /me assumes Jeremy's follow up suggestion/offer is to help compose the
>> rolls, for which Anita is grateful
> 
> Good guess, and yes I'm happy to if desired but if the means of
> identifying Requirements team voters differs from the norm then that
> may take some additional coding to automate.
> 
Wonderful, as usual, thanks for the constant support. Once the direction
the group wants to take in regards to computing the electorate becomes
clear we can move forward hopefully with details in hand.

Thanks Jeremy,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Its a standard way of launching a given openstack service container with 
specified config regardless if its backed with a redhat or ubuntu or source 
based package set that the Operator can rely on having a standardized interface 
to. distro packages don't grantee that kind of thing and don't want to.

To me, its an abstraction api kind of like nova is to kvm vs xen. the nova user 
shouldn't have to care which backend is chosen.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 2:12 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 04:42 PM, Ed Leafe wrote:
> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:
>
>> Its not an "end user" facing thing, but it is an "operator" facing thing.
>
> Well, the end user for Kolla is an operator, no?
>
>> I deploy kolla containers today on non kolla managed systems in production, 
>> and rely on that api being consistent.
>>
>> I'm positive I'm not the only operator doing this either. This sounds like a 
>> consumable api to me.
>
> I don’t think that an API has to be RESTful to be considered an interface for 
> we should avoid duplication.

Application *Programming* Interface. There's nothing that is being
*programmed* or *called* in Kolla's image definitions.

What Kolla is/has is not an API. As Stephen said, it's more of an
Application Binary Interface (ABI). It's not really an ABI, though, in
the traditional sense of the term that I'm used to.

It's an agreed set of package bases, installation procedures/directories
and configuration recipes for OpenStack and infrastructure components.

I see no reason for the OpenStack community to standardize on those
things, frankly. It's like asking RedHat and Canonical to agree to "just
use RPM" as their package specification format. I wonder how that
conversation would go.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

On 2016-07-27 17:38:49 -0400 (-0400), Anita Kuno wrote:
[...]
> /me assumes Jeremy's follow up suggestion/offer is to help compose the
> rolls, for which Anita is grateful

Good guess, and yes I'm happy to if desired but if the means of
identifying Requirements team voters differs from the norm then that
may take some additional coding to automate.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

2016-07-27 Thread Anita Kuno

On 07/27/2016 05:08 PM, Jeremy Stanley wrote:
> On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote:
>> We've started a period of self nomination in preparation for the
>> requirements project fully moving into project (as it's still under Doug
>> Hellmann).
>>
>> We are gathering the self nominations here before we vote next week.
>> https://etherpad.openstack.org/p/requirements-ptl-newton
>>
>> Nominees should also send an email to the openstack-dev list.
> 
> Have you determined whether your electorate are traditional project
> technical contributors (Gerrit owners of changes merged to the
> openstack/requirements repo over the past year) like most teams use,
> or is there a different focus and constituency for this team?
> 

It is a good question. Since they haven't yet determined if they will do
a civs poll or just do a show of hands at a meeting, I was going to give
them a bit and see which direction they wanted to go.

I have an outstanding question to Doug actually on the nature of the
word 'interm' in play currently, because they way I see it a ptl is a
plt and has the same responsibilities as every other ptl adjectives
notwithstanding.

/me assumes Jeremy's follow up suggestion/offer is to help compose the
rolls, for which Anita is grateful

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-27 Thread Clint Byrum

Excerpts from Ed Leafe's message of 2016-07-27 10:59:06 -0500:
> On Jul 27, 2016, at 10:51 AM, Joshua Harlow  wrote:
> 
> >> Whether to have competing projects in the big tent was debated by the TC
> >> at the time and my recollection is that we decided that was a good thing
> >> -- if someone wanted to develop a Nova replacement, then let them do it
> >> in public with the community. It would either win or lose based on its
> >> merits. Why is this not something which can happen here as well?
> > 
> > For real, I (or someone) can start a nova replacement without getting 
> > rejected (or yelled at or ...) by the TC saying it's a competing project??? 
> > Wow, this is news to me...
> 
> No, you can’t start a Nova replacement and still call yourself OpenStack.
> 

Is that true? I thought the thing would be that you'd have to be
running Nova to still use the mark. As long as you're running Nova and
the users can use Nova (the real one), if you also had a competitor to
Nova available, it would just need to pass the relatively low bar of
big tent membership to still be a part of "OpenStack".

> The sense I have gotten over the years from the TC is that gratuitous 
> competition is strongly discouraged. When the Monasca project was being 
> considered for the big tent, there was a *lot* of concern expressed over the 
> partial overlap with Ceilometer. It was only after much reassurance that the 
> overlap was not fundamental that these objections were dropped.
> 
> I have no stake in either Fuel or Kolla, so my only concern is duplication of 
> effort. You can always achieve more working together, though it will never 
> happen as fast as when you go it alone. It’s a trade-off: the needs of the 
> vendor vs. the health of the community.
> 
> 
> -- Ed Leafe
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [glare] Glance virtual midcycle recordings

On 2016-07-27 13:08:35 -0400 (-0400), Nikhil Komawar wrote:
[...]
> There have been some noted instances where people either inadvertently
> or otherwise have updated the etherpad, thus removing the text. Please
> be considerate and watchful of your keyboard when keeping the etherpad open.

Note that you can share read-only URLs to pads (checkbox under the
"share and embed this pad" dropdown that looks like ), for people
to use as a reference if they don't intend to make further
modifications to its content.

> But for the record, here's the content/links that can be accessed if you
> are not a fan of the etherpad colors.
[...]

You can also hide the authorship colours in your browser (the
"settings" dropdown that looks like a gear has a checkbox for that),
if they're annoying.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Pending removal of Scality volume driver

The Cinder policy for driver CI requires that all volume drivers
have a CI reporting on any new patchset. CI's may have some down
time, but if they do not report within a two week period they are
considered out of compliance with our policy.

This is a notification that the Scality OpenStack CI is out of compliance.
It has not reported since April 12th, 2016.

The patch for driver removal has been posted here:

https://review.openstack.org/348032/

If this CI is not brought into compliance, the patch to remove the
driver will be approved one week from now.

Thanks,
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


On 07/27/2016 04:42 PM, Ed Leafe wrote:

On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:


Its not an "end user" facing thing, but it is an "operator" facing thing.


Well, the end user for Kolla is an operator, no?


I deploy kolla containers today on non kolla managed systems in production, and 
rely on that api being consistent.

I'm positive I'm not the only operator doing this either. This sounds like a 
consumable api to me.


I don’t think that an API has to be RESTful to be considered an interface for 
we should avoid duplication.


Application *Programming* Interface. There's nothing that is being 
*programmed* or *called* in Kolla's image definitions.


What Kolla is/has is not an API. As Stephen said, it's more of an 
Application Binary Interface (ABI). It's not really an ABI, though, in 
the traditional sense of the term that I'm used to.


It's an agreed set of package bases, installation procedures/directories 
and configuration recipes for OpenStack and infrastructure components.


I see no reason for the OpenStack community to standardize on those 
things, frankly. It's like asking RedHat and Canonical to agree to "just 
use RPM" as their package specification format. I wonder how that 
conversation would go.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

On 2016-07-27 08:41:17 -0500 (-0500), Matthew Thode wrote:
> We've started a period of self nomination in preparation for the
> requirements project fully moving into project (as it's still under Doug
> Hellmann).
> 
> We are gathering the self nominations here before we vote next week.
> https://etherpad.openstack.org/p/requirements-ptl-newton
> 
> Nominees should also send an email to the openstack-dev list.

Have you determined whether your electorate are traditional project
technical contributors (Gerrit owners of changes merged to the
openstack/requirements repo over the past year) like most teams use,
or is there a different focus and constituency for this team?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Support for volume sharing across multiple VM's

On Wed, Jul 27, 2016 at 09:30:15AM -0700, Adam Lawson wrote:
> I heard there's been some attention given to and progress made supporting
> sharing a single volume with multiple VM's. Where are we along the
> development curve and has anyone been able to get this to work?
> 
> Thanks!
> 
> //adam
> 
> *Adam Lawson*
> 
 Hey Adam,

 We are still working on that functionality. It's ended up a little more
 involved than one would have thought at first glance.

 We've found some issues between how Cinder and Nova interact with each
 other. We've at least identified some of those issues now and are
 working through making that better.

 Once we fix that up, we can then move ahead with getting changes made
 on both sides to be able to support multiattach. Unfortunately there is
 pretty much no chance that we'll get that far in Newton. But at least
 some of the foundation to support that should make it in soon, so maybe
 Ocata (or honestly, to be more realistic, the P release) will have that
 support.

 Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Pending removal of Tegile volume driver

The Cinder policy for driver CI requires that all volume drivers
have a CI reporting on any new patchset. CI's may have some down
time, but if they do not report within a two week period they are
considered out of compliance with our policy.

This is a notification that the Tegile OpenStack CI is out of compliance.
It has not reported since June 24th, 2016.

The patch for driver removal has been posted here:

https://review.openstack.org/348032/

If this CI is not brought into compliance, the patch to remove the
driver will be approved one week from now.

Thanks,
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] snapshots are broken by default with newton and glance v2

2016-07-27 Thread Matt Riedemann

On 7/20/2016 7:01 PM, Nikhil Komawar wrote:

Thanks Matt. The bug looked very descriptive so, I commented my thoughts
there https://bugs.launchpad.net/python-glanceclient/+bug/1596602

On 7/20/16 4:18 PM, Matt Riedemann wrote:

On 7/18/2016 4:41 AM, Erno Kuvaja wrote:

On Mon, Jul 18, 2016 at 5:19 AM, Nikhil Komawar
wrote:

Thanks Matt. I've scheduled for a release of the client this week.

On 7/16/16 4:09 AM, Matt Riedemann wrote:

This is more of a heads up than anything.

Our internal CI is running Tempest with images that don't have
kernel_id or ramdisk_id properties set.

We're running from master so nova defaults to use_glance_v1=False.

Because of this:

https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/compute/api.py#L867-L868

and this:

https://github.com/openstack/nova/blob/47358449d359a287d21426b4e1f18479a4d1fd36/nova/image/glance.py#L835

The snapshot image properties get kernel_id and ramdisk_id set to None
since that's what the glance v2 schema requires.

However, python-glanceclient has it's own outdated copy of the schema
which doesn't allow null values for those properties, see bug:

https://bugs.launchpad.net/python-glanceclient/+bug/1596602

We don't hit this in the community CI because the image that Tempest
uses from devstack has the kernel_id and ramdisk_id properties set:

http://logs.openstack.org/52/335152/1/check/gate-tempest-dsvm-neutron-src-python-glanceclient/d393db9/logs/devstacklog.txt.gz#_2016-06-28_18_40_12_429

But for anyone else upgrading to Newton that has images without those
properties set and doesn't have use_glance_v1=True in nova.conf is
going to be broken.

Since we really want to get people off glance v1 and move to
deprecation in Ocata, we need to get this merged and released:

https://review.openstack.org/#/c/335152/

And bump the minimum required python-glanceclient in
global-requirements for Newton.

I'm not really sure why python-glanceclient even has it's own copy of
the image schema, that seems redundant and error prone given the
glance API already validates that, but it's kind of beside the point
right now.

Thanks,
Nikhil

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi Matt,

Something has broken on the way if that shipped schema actually affect
your operation. That should be used _only_ when the client is called
without connection to the Glance API (for example in a case you have
no env set and you call `glance help`), this is btw the reason why we
have that schema shipped with the client.

As soon as you execute a call that actually interacts with Glance API
we should be pulling the schema from there. So if this is not the
case, we've broken somewhere on the way. I'll try to find time to have
a look.

- Erno

Yeah I guess the schema fix in glanceclient didn't resolve the issue,
but I haven't had the time to dig into the bug since we're doing the
midcycle this week.

For anyone that cares, we figured out the problem. In our case, the
issue was we didn't have /etc/glance/schema-image.json in the
deployment. We're also using full disk images so no kernel_id or
ramdisk_id set on the image (or the snapshot of the instance).

devstack masks all of this because it sets up
/etc/glance/schema-image.json and it uses a multipart uec cirros image
by default, so kernel_id and ramdisk_id are set.

The amount of schema configuration that is possible scares me, given the
glance config option for allow_additional_image_properties (defaults to
true, but if false, you can't even set kernel_id/ramdisk_id and
snapshots would be broken with the libvirt driver and a uec image).

And /etc/glance/schema-image.json is configuration, so it might not be
there, or it might be different.

Nova was passing on assumptions made with the defaults, and how devstack
/ our CI system works, but Nova as a client of glance isn't actually
checking the image schema available when creating images, so we could
potentially hit other issues in the future.

Mike Fedosin has the simple fix for the existing bug though:

https://review.openstack.org/#/c/347971

And it looks like the nova API schema prevents being able to create a
snapshot with metadata that uses null values, so there is some
additional protection in that case.

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-27 Thread Russell Bryant

On Wed, Jul 27, 2016 at 4:15 PM, Zhou, Han  wrote:

>
>
> On Wed, Jul 27, 2016 at 7:15 AM, Russell Bryant 
> wrote:
>
>>
>>
>> On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton  wrote:
>>
>>> > I'd like to see if we can solve the problems more generally.
>>>
>>> We've tried before but we very quickly run into competing requirements
>>> with regards to eventual consistency. For example, asynchronous background
>>> sync doesn't work if someone wants their backend to confirm that port
>>> details are acceptable (e.g. mac isn't in use by some other system outside
>>> of openstack). Then each backend has different methods for detecting what
>>> is out of sync (e.g. config numbers, hashes, or just full syncs on startup)
>>> that each come with their own requirements for how much data needs to be
>>> resent when an inconsistency is detected.
>>>
>>> If we can come to some common ground of what is required by all of them,
>>> then I would love to get some of this built into the ML2 framework.
>>> However, we've discussed this at meetups/mid-cycles/summits and it
>>> inevitably ends up with two people drawing furiously on a whiteboard,
>>> someone crying in the corner, and everyone else arguing about the lack of
>>> parametric polymorphism in Go.
>>>
>>
>> Ha, yes, makes sense that this is really hard to solve in a way that
>> works for everyone ...
>> 
>>
>>
>>> Even between OVN and ODL in this thread, it sounds like the only thing
>>> in common is a background worker that consumes from a queue of tasks in the
>>> db. Maybe realistically the only common thing we can come up with is a
>>> taskflow queue stored in the DB to solve the multiple workers issue...
>>>
>>
>> To clarify, ODL has this background worker and the discussion was
>> whether OVN should try to follow a similar approach.
>>
>> So far, my gut feeling is that it's far too complicated for the problems
>> it would solve.  There's one identified multiple-worker related race
>> condition on updates, but I think we can solve that another way.
>>
>>
> Russell, in fact I think this background worker is the good way to solve
> both problems:
>
> Problem 1. When something failed when updating OVN DB in post-commit: With
> the help of background worker, it can do the retries and the job state can
> be tracked, and with the information proper actions can be taken against
> failure jobs, e.g. cleanups. It is basically a declarative way of
> implementation, which IMHO is a particularly good way in ML2 context,
> because we cannot just rollback Neutron DB changes at failure because it is
> shared by all mech-drivers. (Even in a monolithic plugin, handling the
> partial failures and doing rollback is a big headache).
>
> Problem 2. Race condition because of lack of critical section between
> Neutron DB transaction and post-commit: With the help of journal, the
> ordering is ensured to be the same as DB transaction commits. Protection
> against the journal processing between multiple background workers can be
> properly enforced with the help of DB transaction.
>
> I think ODL and OVN are not the only ones facing these problems. They are
> pretty general to most drivers if not all. It would be great to have a
> common task flow mechanism in ML2, but I'd like to try it in OVN first (if
> no better solution to the problems above).
>

I had another idea for problem 2, at least.  I posted a more detailed
description of the idea on the bug you posted [1].

This is unrelated to problem 1, though.  I guess I was hoping we could just
come up with a better way of doing rollbacks when necessary.

I also had a long term dream of not using the Neutron DB at all, and only
relying on the OVN database.  That seems much less practical now that we've
moved back to ML2.  Maybe it was a crazy idea, anyway.  :-)

[1] https://bugs.launchpad.net/networking-ovn/+bug/1605089


--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On Jul 27, 2016, at 2:42 PM, Fox, Kevin M  wrote:

> Its not an "end user" facing thing, but it is an "operator" facing thing.

Well, the end user for Kolla is an operator, no?

> I deploy kolla containers today on non kolla managed systems in production, 
> and rely on that api being consistent.
> 
> I'm positive I'm not the only operator doing this either. This sounds like a 
> consumable api to me.

I don’t think that an API has to be RESTful to be considered an interface for 
we should avoid duplication.


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [constraints] Updating stable branch URL

On Mon, Jul 11, 2016 at 03:02:45PM -0400, Doug Hellmann wrote:

> Yes, I think updating that branching script is the best course.
> 
> We might want to modify the tox.ini to make it easier to edit with
> sed by defining a variable for the branch. It would be nice if we
> could just read the value from the .gitreview file, but that might
> be trickier than we want to be. The script that creates the branches
> is:
> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/make_stable_branch.sh

I didn;t use a variable as the string is pretty unique.

Here's my first pass.
https://review.openstack.org/348027

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Pending removal of Tintri volume driver

The Cinder policy for driver CI requires that all volume drivers
have a CI reporting on any new patchset. CI's may have some down
time, but if they do not report within a two week period they are
considered out of compliance with our policy.

This is a notification that the Tintri OpenStack CI is out of compliance.
It has not reported since June 9th, 2016.

The patch for driver removal has been posted here:

https://review.openstack.org/348026/

If this CI is not brought into compliance, the patch to remove the
driver will be approved one week from now.

Thanks,
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

2016-07-27 Thread Adrian Otto

On Jul 27, 2016, at 1:26 PM, Hongbin Lu 
> wrote:

Here is the guideline to evaluate an API change: 
http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 . In particular, I highlight the followings:

"""
The following types of changes are acceptable when conditionally added as a new 
API extension:
* Adding an optional property to a resource representation which may be 
supplied by clients, assuming the API previously would ignore this property.
* …
The following types of changes are generally not considered acceptable:
* A change such that a request which was successful before now results in an 
error response
* Changing the semantics of a property in a resource representation which may 
be supplied by clients.
* …
"""

Above all, as Ton mentioned, just adding a new option (--rollback) looks OK. 
However, the implementation should not break the existing behaviors. In 
particular, the proposed patch 
(https://review.openstack.org/#/c/343478/4/magnum/api/controllers/v1/bay.py) 
changes the request parameters and their types, which is considered to be 
unacceptable (unless bumping the microversion). To deal with that, I think 
there are two options:
1. Modify the proposed patch to make it backward-compatible. In particular, it 
should keep the existing properties as is (don’t change their types and 
semantics). The new option should be optional and it should be ignored if 
clients are sending the old requests.

Use the #1 approach above, please.

2. Keep the proposed patch as is, but bumping the microversion. You need to 
wait for this patch [1] to merge, and reference the microversion guide [1] to 
bump the version. In addition, it is highly recommended to follow the standard 
deprecation policy [2]. That means i) print a deprecated warning if old APIs 
are used, ii) document how to migrate from old APIs to new APIs, and iii) 
remove the old APIs after the deprecation period.

You can do this as well, but please don’t consider this an OR choice.

Adrian

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[2] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: July-27-16 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Support for bay rollback may break magnum 
API backward compatibility

Hi Wenzhi,
Looks like you are adding the new --rollback option to bay-update. If the user 
does not specify this new option,
then bay-update behaves the same as before; in other words, if it fails, then 
the state of the bay will be left
in the partially updated mode. Is this correct? If so, this does change the 
API, but does not seem to break
backward compatibility.
Ton Ngo,

"Wenzhi Yu (yuywz)" ---07/27/2016 04:13:07 AM---Hi folks, I am 
working on a patch [1] to add bay rollback machanism on update failure. But it 
seems

From: "Wenzhi Yu (yuywz)" >
To: "openstack-dev" 
>
Date: 07/27/2016 04:13 AM
Subject: [openstack-dev] [magnum] Support for bay rollback may break magnum API 
backward compatibility

Hi folks,

I am working on a patch [1] to add bay rollback machanism on update failure. 
But it seems to break magnum API
backward compatibility.

I'm not sure how to deal with this, can you please give me your suggestion? 
Thanks!

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

2016-07-27

Best Regards,
Wenzhi Yu 
(yuywz)__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

2016-07-27 Thread Adrian Otto

On Jul 27, 2016, at 1:26 PM, Hongbin Lu 
> wrote:

Here is the guideline to evaluate an API change: 
http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 . In particular, I highlight the followings:

"""
The following types of changes are acceptable when conditionally added as a new 
API extension:
* Adding an optional property to a resource representation which may be 
supplied by clients, assuming the API previously would ignore this property.
* …
The following types of changes are generally not considered acceptable:
* A change such that a request which was successful before now results in an 
error response
* Changing the semantics of a property in a resource representation which may 
be supplied by clients.
* …
"""

Above all, as Ton mentioned, just adding a new option (--rollback) looks OK. 
However, the implementation should not break the existing behaviors. In 
particular, the proposed patch 
(https://review.openstack.org/#/c/343478/4/magnum/api/controllers/v1/bay.py) 
changes the request parameters and their types, which is considered to be 
unacceptable (unless bumping the microversion). To deal with that, I think 
there are two options:
1. Modify the proposed patch to make it backward-compatible. In particular, it 
should keep the existing properties as is (don’t change their types and 
semantics). The new option should be optional and it should be ignored if 
clients are sending the old requests.

Use the #1 approach above, please.

2. Keep the proposed patch as is, but bumping the microversion. You need to 
wait for this patch [1] to merge, and reference the microversion guide [1] to 
bump the version. In addition, it is highly recommended to follow the standard 
deprecation policy [2]. That means i) print a deprecated warning if old APIs 
are used, ii) document how to migrate from old APIs to new APIs, and iii) 
remove the old APIs after the deprecation period.

You can do this as well, but please don’t consider this an OR choice.

Adrian

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[2] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: July-27-16 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Support for bay rollback may break magnum 
API backward compatibility

Hi Wenzhi,
Looks like you are adding the new --rollback option to bay-update. If the user 
does not specify this new option,
then bay-update behaves the same as before; in other words, if it fails, then 
the state of the bay will be left
in the partially updated mode. Is this correct? If so, this does change the 
API, but does not seem to break
backward compatibility.
Ton Ngo,

"Wenzhi Yu (yuywz)" ---07/27/2016 04:13:07 AM---Hi folks, I am 
working on a patch [1] to add bay rollback machanism on update failure. But it 
seems

From: "Wenzhi Yu (yuywz)" >
To: "openstack-dev" 
>
Date: 07/27/2016 04:13 AM
Subject: [openstack-dev] [magnum] Support for bay rollback may break magnum API 
backward compatibility

Hi folks,

I am working on a patch [1] to add bay rollback machanism on update failure. 
But it seems to break magnum API
backward compatibility.

I'm not sure how to deal with this, can you please give me your suggestion? 
Thanks!

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

2016-07-27

Best Regards,
Wenzhi Yu 
(yuywz)__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Wed, Jul 27, 2016 at 10:23:30PM +0200, Ihar Hrachyshka wrote:

> I only suggest Armando is not dragged into it, the release liaison
> (currently me) should be able to handle the request if it comes from the
> core team for the subproject.

Good point.  I defaulted to PTL but you're right the release liason is also
totally reasonable.

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Pending removal of X-IO volume driver

The Cinder policy for driver CI requires that all volume drivers
have a CI reporting on any new patchset. CI's may have some down
time, but if they do not report within a two week period they are
considered out of compliance with our policy.

This is a notification that the X-IO OpenStack CI is out of compliance.
It has not reported since March 18th, 2016.

The patch for driver removal has been posted here:

https://review.openstack.org/348022

If this CI is not brought into compliance, the patch to remove the
driver will be approved one week from now.

Thanks,
Sean McGinnis (smcginnis)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

2016-07-27 Thread Hongbin Lu

Here is the guideline to evaluate an API change: 
http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 . In particular, I highlight the followings:

"""
The following types of changes are acceptable when conditionally added as a new 
API extension:
* Adding an optional property to a resource representation which may be 
supplied by clients, assuming the API previously would ignore this property.
* ...
The following types of changes are generally not considered acceptable:
* A change such that a request which was successful before now results in an 
error response
* Changing the semantics of a property in a resource representation which may 
be supplied by clients.
* ...
"""

Above all, as Ton mentioned, just adding a new option (--rollback) looks OK. 
However, the implementation should not break the existing behaviors. In 
particular, the proposed patch 
(https://review.openstack.org/#/c/343478/4/magnum/api/controllers/v1/bay.py) 
changes the request parameters and their types, which is considered to be 
unacceptable (unless bumping the microversion). To deal with that, I think 
there are two options:
1. Modify the proposed patch to make it backward-compatible. In particular, it 
should keep the existing properties as is (don't change their types and 
semantics). The new option should be optional and it should be ignored if 
clients are sending the old requests.
2. Keep the proposed patch as is, but bumping the microversion. You need to 
wait for this patch [1] to merge, and reference the microversion guide [1] to 
bump the version. In addition, it is highly recommended to follow the standard 
deprecation policy [2]. That means i) print a deprecated warning if old APIs 
are used, ii) document how to migrate from old APIs to new APIs, and iii) 
remove the old APIs after the deprecation period.

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[2] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: July-27-16 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Support for bay rollback may break magnum 
API backward compatibility


Hi Wenzhi,
Looks like you are adding the new --rollback option to bay-update. If the user 
does not specify this new option,
then bay-update behaves the same as before; in other words, if it fails, then 
the state of the bay will be left
in the partially updated mode. Is this correct? If so, this does change the 
API, but does not seem to break
backward compatibility.
Ton Ngo,

[Inactive hide details for "Wenzhi Yu (yuywz)" ---07/27/2016 04:13:07 AM---Hi 
folks, I am working on a patch [1] to add bay roll]"Wenzhi Yu (yuywz)" 
---07/27/2016 04:13:07 AM---Hi folks, I am working on a patch [1] to add bay 
rollback machanism on update failure. But it seems

From: "Wenzhi Yu (yuywz)" >
To: "openstack-dev" 
>
Date: 07/27/2016 04:13 AM
Subject: [openstack-dev] [magnum] Support for bay rollback may break magnum API 
backward compatibility





Hi folks,

I am working on a patch [1] to add bay rollback machanism on update failure. 
But it seems to break magnum API
backward compatibility.

I'm not sure how to deal with this, can you please give me your suggestion? 
Thanks!

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

2016-07-27


Best Regards,
Wenzhi Yu 
(yuywz)__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

2016-07-27 Thread Ihar Hrachyshka


Tony Breeds  wrote:


On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:

Hi,
Is anyone looking at creating a stable/mitaka version? What if someone  
want

to use this for stable/mitaka?


If that's a thing you need it's a matter of Armando asking the release  
managers

to create it.


I only suggest Armando is not dragged into it, the release liaison  
(currently me) should be able to handle the request if it comes from the  
core team for the subproject.


Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-27 Thread Zhou, Han

On Wed, Jul 27, 2016 at 7:15 AM, Russell Bryant  wrote:

>
>
> On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton  wrote:
>
>> > I'd like to see if we can solve the problems more generally.
>>
>> We've tried before but we very quickly run into competing requirements
>> with regards to eventual consistency. For example, asynchronous background
>> sync doesn't work if someone wants their backend to confirm that port
>> details are acceptable (e.g. mac isn't in use by some other system outside
>> of openstack). Then each backend has different methods for detecting what
>> is out of sync (e.g. config numbers, hashes, or just full syncs on startup)
>> that each come with their own requirements for how much data needs to be
>> resent when an inconsistency is detected.
>>
>> If we can come to some common ground of what is required by all of them,
>> then I would love to get some of this built into the ML2 framework.
>> However, we've discussed this at meetups/mid-cycles/summits and it
>> inevitably ends up with two people drawing furiously on a whiteboard,
>> someone crying in the corner, and everyone else arguing about the lack of
>> parametric polymorphism in Go.
>>
>
> Ha, yes, makes sense that this is really hard to solve in a way that
> works for everyone ...
> 
>
>
>> Even between OVN and ODL in this thread, it sounds like the only thing in
>> common is a background worker that consumes from a queue of tasks in the
>> db. Maybe realistically the only common thing we can come up with is a
>> taskflow queue stored in the DB to solve the multiple workers issue...
>>
>
> To clarify, ODL has this background worker and the discussion was whether
> OVN should try to follow a similar approach.
>
> So far, my gut feeling is that it's far too complicated for the problems
> it would solve.  There's one identified multiple-worker related race
> condition on updates, but I think we can solve that another way.
>
>
Russell, in fact I think this background worker is the good way to solve
both problems:

Problem 1. When something failed when updating OVN DB in post-commit: With
the help of background worker, it can do the retries and the job state can
be tracked, and with the information proper actions can be taken against
failure jobs, e.g. cleanups. It is basically a declarative way of
implementation, which IMHO is a particularly good way in ML2 context,
because we cannot just rollback Neutron DB changes at failure because it is
shared by all mech-drivers. (Even in a monolithic plugin, handling the
partial failures and doing rollback is a big headache).

Problem 2. Race condition because of lack of critical section between
Neutron DB transaction and post-commit: With the help of journal, the
ordering is ensured to be the same as DB transaction commits. Protection
against the journal processing between multiple background workers can be
properly enforced with the help of DB transaction.

I think ODL and OVN are not the only ones facing these problems. They are
pretty general to most drivers if not all. It would be great to have a
common task flow mechanism in ML2, but I'd like to try it in OVN first (if
no better solution to the problems above).


>
>
>> On Tue, Jul 26, 2016 at 11:31 AM, Russell Bryant 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique 
>>> wrote:
>>>
 Thanks for the comments Amitabha.
 Please see comments inline

 On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas 
 wrote:

> Hi Numan,
>
> Thanks for the proposal. We have also been thinking about this
> use-case.
>
> If I’m reading this accurately (and I may not be), it seems that the
> proposal is to not have any OVN NB (CUD) operations (R operations outside
> the scope) done by the api_worker threads but rather by a new journal
> thread.
>
>
 Correct.
 


> If this is indeed the case, I’d like to consider the scenario when
> there any N neutron nodes, each node with M worker threads. The journal
> thread at the each node contain list of pending operations. Could there be
> (sequence) dependency in the pending operations amongst each the journal
> threads in the nodes that prevents them from getting applied (for e.g.
> Logical_Router_Port and Logical_Switch_Port inter-dependency), because we
> are returning success on neutron operations that have still not been
> committed to the NB DB.
>
>
 I
 ts a valid scenario and should be designed properly to handle such
 scenarios in case we take this approach.

>>>
>>> I believe a new table in the Neutron DB is used to synchronize all of
>>> the journal threads.
>>> 
>>> Also note that OVN currently has no custom tables in the Neutron
>>> database and it would be *very* good to keep it that way if we can.
>>>
>>>

 

> Couple of

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Its not an "end user" facing thing, but it is an "operator" facing thing.

I deploy kolla containers today on non kolla managed systems in production, and 
rely on that api being consistent.

I'm positive I'm not the only operator doing this either. This sounds like a 
consumable api to me.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 12:02 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 01:59 PM, Fox, Kevin M wrote:
> Kolla is providing a public api for docker containers and kubernetes 
> templates though. So its not just a deployment tool issue. Its not 
> specifically rest, but does that matter?

Yes, it matters.

Kolla isn't providing a user-interfacing HTTP API for doing something in
a cloud. Kolla is providing a prescriptive way of building Docker images
from a set of Dockerfiles and various configuration file templates. That
isn't a consumable API. That's a reference manual.

Best,
-jay

> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Wednesday, July 27, 2016 10:36 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is 
> getting Fuel CCP (docker/k8s) kicked off
>
> On 07/27/2016 10:10 AM, Chris Friesen wrote:
>> On 07/27/2016 09:59 AM, Ed Leafe wrote:
>>> On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
>>> wrote:
>>>
> Whether to have competing projects in the big tent was debated by
> the TC
> at the time and my recollection is that we decided that was a good
> thing
> -- if someone wanted to develop a Nova replacement, then let them do it
> in public with the community. It would either win or lose based on its
> merits. Why is this not something which can happen here as well?

 For real, I (or someone) can start a nova replacement without getting
 rejected (or yelled at or ...) by the TC saying it's a competing
 project??? Wow, this is news to me...
>>>
>>> No, you can’t start a Nova replacement and still call yourself OpenStack.
>>>
>>> The sense I have gotten over the years from the TC is that gratuitous
>>> competition is strongly discouraged.
>>
>> I seem to recall that back during the "big tent" discussion people were
>> talking about allowing competing projects that performed the same task,
>> and letting natural selection decide which one survived.
>>
>> For example, at
>> "http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/;
>> Jay Pipes said that being under the big tent should not mean that the
>> project is the only/best way to provide a specific function to OpenStack
>> users.
>>
>> On the other hand, the OpenStack new projects requirements *do*
>> explicitly state that "Where it makes sense, the project cooperates with
>> existing projects rather than gratuitously competing or reinventing the
>> wheel."
>>
>> Maybe it boils down to the definition of "gratuitous" competition.
>
> For the record I think I've always been clear that I don't see
> competition as a bad thing within the OpenStack ecosystem however I have
> always been a proponent of having a *single consistent REST API* for a
> particular service type. I think innovation should happen at the
> implementation layer, but the public HTTP APIs should be collated and
> reviewed for overlap and inconsistencies.
>
> This was why in the past I haven't raised a stink about multiple
> deployment tools, since there was no OpenStack HTTP API for deployment
> of OpenStack itself. But I have absolutely raised concerns over overlap
> of HTTP APIs, like is the case with Monasca and various Telemetry
> project APIs. Again, implementation diversity cool. Public HTTP API
> diversity, not cool.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-27 Thread Steven Dake (stdake)

One correction inside:

On 7/27/16, 12:02 PM, "Jay Pipes"  wrote:

>On 07/27/2016 01:59 PM, Fox, Kevin M wrote:
>> Kolla is providing a public api for docker containers and kubernetes
>>templates though. So its not just a deployment tool issue. Its not
>>specifically rest, but does that matter?
>
>Yes, it matters.
>
>Kolla isn't providing a user-interfacing HTTP API for doing something in
>a cloud. Kolla is providing a prescriptive way of building Docker images
>from a set of Dockerfiles and various configuration file templates. That
>isn't a consumable API. That's a reference manual.
>
>Best,
>-jay

Not that I think this discussion is all that productive but it should be
based on facts.  Kolla container images do provide a standardized
consumable ABI and we have claimed such for over two cycles.

Regards
-steve

>
>> 
>> From: Jay Pipes [jaypi...@gmail.com]
>> Sent: Wednesday, July 27, 2016 10:36 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is
>>getting Fuel CCP (docker/k8s) kicked off
>>
>> On 07/27/2016 10:10 AM, Chris Friesen wrote:
>>> On 07/27/2016 09:59 AM, Ed Leafe wrote:
 On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
 wrote:

>> Whether to have competing projects in the big tent was debated by
>> the TC
>> at the time and my recollection is that we decided that was a good
>> thing
>> -- if someone wanted to develop a Nova replacement, then let them
>>do it
>> in public with the community. It would either win or lose based on
>>its
>> merits. Why is this not something which can happen here as well?
>
> For real, I (or someone) can start a nova replacement without getting
> rejected (or yelled at or ...) by the TC saying it's a competing
> project??? Wow, this is news to me...

 No, you can¹t start a Nova replacement and still call yourself
OpenStack.

 The sense I have gotten over the years from the TC is that gratuitous
 competition is strongly discouraged.
>>>
>>> I seem to recall that back during the "big tent" discussion people were
>>> talking about allowing competing projects that performed the same task,
>>> and letting natural selection decide which one survived.
>>>
>>> For example, at
>>> 
>>>"http://www.joinfu.com/2014/09/answering-the-existential-question-in-ope
>>>nstack/"
>>> Jay Pipes said that being under the big tent should not mean that the
>>> project is the only/best way to provide a specific function to
>>>OpenStack
>>> users.
>>>
>>> On the other hand, the OpenStack new projects requirements *do*
>>> explicitly state that "Where it makes sense, the project cooperates
>>>with
>>> existing projects rather than gratuitously competing or reinventing the
>>> wheel."
>>>
>>> Maybe it boils down to the definition of "gratuitous" competition.
>>
>> For the record I think I've always been clear that I don't see
>> competition as a bad thing within the OpenStack ecosystem however I have
>> always been a proponent of having a *single consistent REST API* for a
>> particular service type. I think innovation should happen at the
>> implementation layer, but the public HTTP APIs should be collated and
>> reviewed for overlap and inconsistencies.
>>
>> This was why in the past I haven't raised a stink about multiple
>> deployment tools, since there was no OpenStack HTTP API for deployment
>> of OpenStack itself. But I have absolutely raised concerns over overlap
>> of HTTP APIs, like is the case with Monasca and various Telemetry
>> project APIs. Again, implementation diversity cool. Public HTTP API
>> diversity, not cool.
>>
>> Best,
>> -jay
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
> Hi,
> Is anyone looking at creating a stable/mitaka version? What if someone want
> to use this for stable/mitaka?

If that's a thing you need it's a matter of Armando asking the release managers
to create it.

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Project mascot - propose your choice/cast your vote

2016-07-27 Thread Armando M.

On 25 July 2016 at 10:52, Armando M.  wrote:

> On 14 July 2016 at 10:00, Armando M.  wrote:
>
>> Hi Neutrinos,
>>
>> Based on proposal [1], I prepared an etherpad to allow us to choose
>> collaboratively a set of candidates for our mascot. Propose/vote away on
>> [2]. You have time until Friday, July 22nd.
>>
>
> The deadline has passed, we have now a list of selected candidates to
> choose from.
>
> Please cast your vote [1]!
>
> Cheers,
> Armando
>
> [1]
> https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link
>


Today is the deadline to submit mascot candidates for priority
consideration to Heidi Joy @Foundation. If you have not voted so far and
would like to, please do. I will close the poll [2] by the EOB (PST
timezone), and submit the outcome of the poll later in the day.

Cheers,
Armando

[1] http://www.openstack.org/project-mascots

[2]
https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link


>
>
>>
>> After the deadline the most voted ones (depending on the number) will be
>> sent to Heidi Joy @Foundation for the next step in the selection process.
>>
>> Feel free to reach out if you have any questions/suggestions.
>>
>> Happy hacking!
>> Armando
>>
>> [1] http://www.openstack.org/project-mascots
>> [2] https://etherpad.openstack.org/p/neutron-project-mascot
>>
>
> Today was the deadline for
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][neutron] python-neutronclient 5.0.0 release (newton)

2016-07-27 Thread no-reply

We are high-spirited to announce the release of:

python-neutronclient 5.0.0: CLI and Client Library for OpenStack
Networking

This release is part of the newton release series.

With source available at:

https://git.openstack.org/cgit/openstack/python-neutronclient

With package available at:

https://pypi.python.org/pypi/python-neutronclient

Please report issues through launchpad:

https://bugs.launchpad.net/python-neutronclient

For more details, please see below.

5.0.0
^


Deprecation Notes
*

* Keystone v3 support for CLI

  * Using 'tenant_id' and 'tenant_name' arguments in API bindings is
deprecated. Use 'project_id' and 'project_name' arguments instead.


Bug Fixes
*

* CLI support to set QoS policy as not shared if it was shared
  before. The "qos-policy-update" command include a "--no-shared"
  option. Closes bug 1590942 (https://bugs.launchpad.net/python-
  neutronclient/+bug/1590942).

Changes in python-neutronclient 4.2.0..5.0.0


ec20f7f Fix string interpolation at logging call
3b1c538 Updated from global requirements
6bc4685 Add functional test hook for fwaas command
6ba4f31 HAProxy uses milliseconds for its timeout values.
d63a92a Base OSC plugin support
1d7c992 Updated from global requirements
0cbd30b Make USER_AGENT variable global
3832d53 Trivial: missing comma in the docs
1828552 Fixed --insecure not taking effect when specified
e917f21 Fix the problem of mox in test_shell.py
f3bea7e Updated from global requirements
8585c14 Trivial Fix: Fix typo
5f079fe improve readme contents
521ff7c Add no-shared option to qos-policy-update command
6d5356a Updated from global requirements
81a3d1f Add in missing translations
bbb7a88 Trivial: ignore openstack/common in flake8 exclude list
343e4b1 Update for API bindings
925d44a Remove unnecessary executable permissions
53a59e5 Updated from global requirements
954375b Update tempest_lib to tempest.lib
78d778c Constraint tox targets with upper-constraints.txt
ea0dfb1 Make purge supports dvr router's interface
35ce1a5 Switched from fixtures.MonkeyPatch to mock.patch
9e4f826 tests: removed mocking for Client.get_attr_metadata
51f07b8 Update the home-page with developer documentation
a065d20 Address pairs help missing space
2e048fd Devref: Add dynamic routing to OSC transition
04cf26d Updated from global requirements
98fc6c5 Updated from global requirements
b16bc6c Support sha256 for vpn-ikepolicy and vpn-ipsecpolicy
37ec942 Fixes unclear error when no --pool-prefix given
feba9bb Updated from global requirements
0927632 Added missing help text for 'purge' command
84aebc2 Fix random failure of security group unit test
d453846 Remove the last remaining vendor code
270da35 Update help information for lbaasv2 CLIs
3faf02f Devref: Newton updates for transition to OSC
6c82731 Devref Update: Transition to OpenStack Client
84cd3c4 Fix duplicate entries in list_columns while extending the list
9287040 Remove unnecessary entry from old relnotes


Diffstat (except docs and test files)
-

README.rst |  29 ++-
neutronclient/client.py|  36 +--
neutronclient/common/clientmanager.py  |  18 +-
neutronclient/neutron/client.py|   2 +-
neutronclient/neutron/v2_0/address_scope.py|   0
neutronclient/neutron/v2_0/agentscheduler.py   |   3 +-
.../neutron/v2_0/auto_allocated_topology.py|   0
neutronclient/neutron/v2_0/bgp/speaker.py  |   0
neutronclient/neutron/v2_0/lb/healthmonitor.py |   7 +-
neutronclient/neutron/v2_0/lb/v2/healthmonitor.py  | 102 
neutronclient/neutron/v2_0/lb/v2/listener.py   |  79 +++---
neutronclient/neutron/v2_0/lb/v2/loadbalancer.py   |  45 +++-
neutronclient/neutron/v2_0/lb/v2/member.py |  51 ++--
neutronclient/neutron/v2_0/lb/v2/pool.py   |  89 ---
neutronclient/neutron/v2_0/nsx/__init__.py |   0
neutronclient/neutron/v2_0/nsx/networkgateway.py   | 265 -
neutronclient/neutron/v2_0/nsx/qos_queue.py|  82 ---
neutronclient/neutron/v2_0/port.py |   2 +-
neutronclient/neutron/v2_0/purge.py|   5 +-
neutronclient/neutron/v2_0/qos/__init__.py |   0
neutronclient/neutron/v2_0/qos/policy.py   |  13 +-
neutronclient/neutron/v2_0/subnet.py   |   6 +-
neutronclient/neutron/v2_0/subnetpool.py   |   9 +-
neutronclient/neutron/v2_0/vpn/ikepolicy.py|   2 +-
neutronclient/neutron/v2_0/vpn/ipsecpolicy.py  |   2 +-
neutronclient/osc/__init__.py  |   0
neutronclient/osc/plugin.py|  61 +
neutronclient/osc/v2/__init__.py   |   0
neutronclient/osc/v2/dynamic_routing/__init__.py   |   0
neutronclient/osc/v2/fwaas/__init__.py |   0
neutronclient/osc/v2/lbaas/__init__.py |   0

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


On 07/27/2016 01:59 PM, Fox, Kevin M wrote:

Kolla is providing a public api for docker containers and kubernetes templates 
though. So its not just a deployment tool issue. Its not specifically rest, but 
does that matter?


Yes, it matters.

Kolla isn't providing a user-interfacing HTTP API for doing something in 
a cloud. Kolla is providing a prescriptive way of building Docker images 
from a set of Dockerfiles and various configuration file templates. That 
isn't a consumable API. That's a reference manual.


Best,
-jay



From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 10:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 10:10 AM, Chris Friesen wrote:

On 07/27/2016 09:59 AM, Ed Leafe wrote:

On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
wrote:


Whether to have competing projects in the big tent was debated by
the TC
at the time and my recollection is that we decided that was a good
thing
-- if someone wanted to develop a Nova replacement, then let them do it
in public with the community. It would either win or lose based on its
merits. Why is this not something which can happen here as well?


For real, I (or someone) can start a nova replacement without getting
rejected (or yelled at or ...) by the TC saying it's a competing
project??? Wow, this is news to me...


No, you can’t start a Nova replacement and still call yourself OpenStack.

The sense I have gotten over the years from the TC is that gratuitous
competition is strongly discouraged.


I seem to recall that back during the "big tent" discussion people were
talking about allowing competing projects that performed the same task,
and letting natural selection decide which one survived.

For example, at
"http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/;
Jay Pipes said that being under the big tent should not mean that the
project is the only/best way to provide a specific function to OpenStack
users.

On the other hand, the OpenStack new projects requirements *do*
explicitly state that "Where it makes sense, the project cooperates with
existing projects rather than gratuitously competing or reinventing the
wheel."

Maybe it boils down to the definition of "gratuitous" competition.


For the record I think I've always been clear that I don't see
competition as a bad thing within the OpenStack ecosystem however I have
always been a proponent of having a *single consistent REST API* for a
particular service type. I think innovation should happen at the
implementation layer, but the public HTTP APIs should be collated and
reviewed for overlap and inconsistencies.

This was why in the past I haven't raised a stink about multiple
deployment tools, since there was no OpenStack HTTP API for deployment
of OpenStack itself. But I have absolutely raised concerns over overlap
of HTTP APIs, like is the case with Monasca and various Telemetry
project APIs. Again, implementation diversity cool. Public HTTP API
diversity, not cool.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

2016-07-27 Thread Terry Wilson

On Tue, Jul 26, 2016 at 10:04 AM, Jakub Libosvar  wrote:
> On 26/07/16 16:56, Assaf Muller wrote:
>>
>> We've hit critical mass from cores interesting in the testing area.
>>
>> Welcome Jakub to the core reviewer team. May you enjoy staring at the
>> Gerrit interface and getting yelled at by people... It's a glamorous
>> life.
>
>
> Thanks everyone for support! I'll try to do my best :)

Congrats!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][neutron] neutron-lib 0.3.0 release (newton)

2016-07-27 Thread no-reply

We are high-spirited to announce the release of:

neutron-lib 0.3.0: Neutron shared routines and utilities

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/neutron-lib

With package available at:

https://pypi.python.org/pypi/neutron-lib

Please report issues through launchpad:

http://bugs.launchpad.net/neutron

For more details, please see below.

Changes in neutron-lib 0.2.0..0.3.0
---

1d44493 Remove discover from test-requirements
37c5a03 Add validator to test integers
7c09268 Deprecate N523 check that forbids oslo.* imports
0316d00 devref for public API docstring
cf874bf Migration report: validate that bc is installed
23aea4e add tags to api-ref files for the content verification phase
9dc6770 Add tool to track migration to neutron-lib
5cdbb04 Document release steps for neutron-lib
5f4af17 Expand the API reference Table of Content
911c1ac Updated from global requirements
7875c52 Fix simple typo
de11a26 Tweak validation logic for subport validator
646d6f1 Updated from global requirements
9157ed5 Update documents to address some issues
159e04e Updated from global requirements
64991fd Rehome IPV6_MODES constants
3fcd939 Update validator accessors
112eef6 Forbid eventlet based code
6f09e4d Make the constant Sentinel() class public
84491d2 100% unit test coverage for hacking/checks.py
ba717a0 Localized exception message hacking check
0a6a347 Updated from global requirements
0ac922e WADL to RST migration
b82347d Add translation validations to the hacking policy
695eccf Updated from global requirements
e419f24 Fix E128 hacking errors and enable it
1cb7708 TrivialFix: Fix a bad indentation in a doc file
142c2b7 Enable local hacking rule in neutron-lib
4031e12 Hacking: update iteritems hacking message
c607b44 Add Neutron L3 agent types
e336158 Fix exception for invalid type
f54a138 Add subport validator for vlan-aware-vms
ea2bcdd Updated from global requirements
445e74d Remove unused oslo.service requirement
bb13c50 Fixed type:dict validator passes unexpected keys


Diffstat (except docs and test files)
-

.gitignore |1 +
HACKING.rst|6 +-
api-ref/source/conf.py |  222 ++
api-ref/source/index.rst   |9 +
.../extensions/extension-show-response.json|9 +
.../extensions/extensions-list-response.json   |  123 +
.../samples/firewalls/firewall-create-request.json |6 +
.../firewalls/firewall-create-response.json|   14 +
.../firewalls/firewall-policies-list-response.json |   15 +
.../firewalls/firewall-policy-create-request.json  |8 +
.../firewalls/firewall-policy-create-response.json |   13 +
.../firewall-policy-insert-rule-request.json   |5 +
.../firewall-policy-insert-rule-response.json  |   14 +
.../firewall-policy-remove-rule-request.json   |3 +
.../firewall-policy-remove-rule-response.json  |   13 +
.../firewalls/firewall-policy-show-response.json   |   13 +
.../firewalls/firewall-policy-update-request.json  |8 +
.../firewalls/firewall-policy-update-response.json |   14 +
.../firewalls/firewall-rule-create-request.json|9 +
.../firewalls/firewall-rule-create-response.json   |   19 +
.../firewalls/firewall-rule-show-response.json |   19 +
.../firewalls/firewall-rule-update-request.json|5 +
.../firewalls/firewall-rule-update-response.json   |   19 +
.../firewalls/firewall-rules-list-response.json|   21 +
.../samples/firewalls/firewall-show-response.json  |   14 +
.../samples/firewalls/firewall-update-request.json |5 +
.../firewalls/firewall-update-response.json|   14 +
.../samples/firewalls/firewalls-list-response.json |   16 +
.../samples/flavors/flavor-associate-request.json  |5 +
.../samples/flavors/flavor-associate-response.json |5 +
.../samples/flavors/flavor-create-request.json |8 +
.../samples/flavors/flavor-create-response.json|   10 +
.../samples/flavors/flavor-show-response.json  |   10 +
.../samples/flavors/flavor-update-request.json |7 +
.../samples/flavors/flavor-update-response.json|   10 +
.../samples/flavors/flavors-list-response.json |   12 +
.../flavors/service-profile-create-request.json|8 +
.../flavors/service-profile-create-response.json   |9 +
.../flavors/service-profile-show-response.json |9 +
.../flavors/service-profile-update-request.json|8 +
.../flavors/service-profile-update-response.json   |9 +
.../flavors/service-profiles-list-response.json|   18 +
.../lbaas/healthmonitor-associate-request.json |5 +
.../lbaas/healthmonitor-associate-response.json|3 +
.../lbaas/healthmonitor-create-request.json|   12 +
.../lbaas/healthmonitor-create-response.json   |   15 +

Re: [openstack-dev] [release] Independent tag and stable branches

On 2016-07-27 14:46:18 +0200 (+0200), Julien Danjou wrote:
> If I understand correctly, I think this is what we do to solve what you
> describe:
> 
>   
> https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/gnocchi.yaml#n25

Yep, I missed that when skimming your jobs, thanks!

Though that points out that you have a very incomplete mapping
defined, so presumably you've only added each of those entries after
discovering that an attempted backport failed tests.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [sahara] using 'sahara' cli commands is deprecated, how widely it's used?

2016-07-27 Thread Vitaly Gridnev

Hello,

In Mitaka release sahara team marked old cli commands starting with
'sahara' as deprecated, since new openstackclient plugin was implemented
('openstack dataprocessing'), and it has all features that old cli has.

The question is the following: is there something that can stop us from
removing old CLI from saharaclient code in Newton or Ocata (which is
probably much better choice)?

Would love to see feedback on topic.

-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

2016-07-27 Thread Maxime Belanger

+1 on this,

Still you loose all the great stuff about the containers but it is a first step 
towards native container orchestration platform.

From: Devdatta Kulkarni 
Sent: July 27, 2016 12:21:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][rfc] Booting docker images using nova 
libvirt

Hi Sudipta,

There is another approach you can consider which does not need any changes to 
Nova.

The approach works as follows:
- Save the container image tar in Swift
- Generate a Swift tempURL for the container file
- Boot Nova vm and pass instructions for following steps through cloud init / 
user data
  - download the container file from Swift (wget)
  - load it (docker load)
  - run it (docker run)

We have implemented this approach in Solum (where we use Heat for deploying a 
VM and
then run application container on it  by providing above instructions through 
user_data of the HOT).

Thanks,
Devdatta

-

From: Sudipta Biswas 
Sent: Wednesday, July 27, 2016 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

Premise:

While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel for 
multiple containers.
- They already have a significant investment (including skills) in OpenStack's 
Virtual Machine workflow and would like to re-use it as much as possible.
- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers workflows 
which already tries to address the first point. But we wanted to arrive at an 
approach that addresses all the above three in context of OpenStack Nova with 
minimalist changes.

Design Considerations:

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.

The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum operating 
system required to run it.
The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the community 
before proposing this as a spec or blueprint.

Approach 1

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in glance were 
a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual machine.

Following are some of the changes to the OpenStack code that implements this 
approach:

1. Define a new conf parameter in nova called – 
base_vm_image=/var/lib/libvirt/images/baseimage.qcow2
This option is used to specify the base VM image.

2. define a new sub_virt_type = container in nova conf. Setting this parameter 
will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type – this workflow will not work at this 
moment.

3. In the virt/libvirt/driver.py we do the following based on the sub_virt_type 
= container:

- We create a qcow2 disk from the base_vm_image and expose that 'disk' as the 
boot disk for the virtual machine.
 Note – this is very similar to a regular virtual machine boot minus the fact 
that the image is not downloaded from
glance but instead it is present on the host.

- We download the docker image into the /var/lib/nova/instances/_base directory 
and then for each new virtual machine boot – we create a new directory 
/var/lib/nova/instances/ as it's and copy the docker filesystem 
to it. Note – there are subsequent improvements to this idea that could be 
performed around the lines of using a union filesystem approach.
- The step above allows each virtual machine to have a different copy of the 
filesystem.
- We create a 'passthrough' mount of the filesystem via libvirt. This code is 
also present in the nova libvirt driver and we just trigger it based on our 
sub_virt_type parameter.

4. A cloud init – userdata is provided that looks somewhat like this:

runcmd:
  - mount -t 9p -o trans=virtio share_dir /mnt
  - chroot /mnt /bin/

The command_to_run is usually the entrypoint to for the docker image.

There could be better approaches to determine the entrypoint as well (say from 
docker image metadata).

Approach 2.

In this approach, the workflow remains the same as the first one with the 
exception that the
docker image is changed into a qcow2 image using a tool like virt-make-fs 
before uploading it to glance, instead of a tar file.

A tool like virt-make-fs can convert a tar file to a qcow2 image very easily.

This image is then downloaded on the compute node and a qcow2 disk is 
created/attached to the virtual machine that boots using the

Re: [openstack-dev] [heat][requirements] Re: [Openstack-stable-maint] Stable check of openstack/heat failed

On Wed, Jul 27, 2016 at 02:20:38PM +0800, Ethan Lynn wrote:
> Hi Tony,
>   I submit a patch to use upper-constraints for review,
>   https://review.openstack.org/#/c/347639/
>    . Let’s wait for the feedback
>   and results.

Thanks.  I see that you have reviews for master, mitaka and liberty.  Thanks 
for doign that.

Once the mast patch merges let me know and I'll help approve the stable patches

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla][kolla-kubernetes]

2016-07-27 Thread Ryan Hallisey

Hi all,

The kolla-kubernetes project is in need of introducing some changes into
kolla's globals.yml.  This could quickly become an issue because the community
does not want to have too many variables exposed and create a mess for any
backports.

In order to get kolla-kubernetes unblocked, kolla-kubernetes users will need
to copy/paste variables into the globals.yml.  This will be documented on the
kolla-kubernetes side. The Kolla config will be setup to pickup these vars
and make any changes.  This solution will work for the time being until Kolla
reaches the conclusion of the N cycle and the community evaluates a repo split
and a config split.

https://review.openstack.org/#/c/327925/

Thanks,
Ryan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Kolla is providing a public api for docker containers and kubernetes templates 
though. So its not just a deployment tool issue. Its not specifically rest, but 
does that matter?

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 10:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On 07/27/2016 10:10 AM, Chris Friesen wrote:
> On 07/27/2016 09:59 AM, Ed Leafe wrote:
>> On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
>> wrote:
>>
 Whether to have competing projects in the big tent was debated by
 the TC
 at the time and my recollection is that we decided that was a good
 thing
 -- if someone wanted to develop a Nova replacement, then let them do it
 in public with the community. It would either win or lose based on its
 merits. Why is this not something which can happen here as well?
>>>
>>> For real, I (or someone) can start a nova replacement without getting
>>> rejected (or yelled at or ...) by the TC saying it's a competing
>>> project??? Wow, this is news to me...
>>
>> No, you can’t start a Nova replacement and still call yourself OpenStack.
>>
>> The sense I have gotten over the years from the TC is that gratuitous
>> competition is strongly discouraged.
>
> I seem to recall that back during the "big tent" discussion people were
> talking about allowing competing projects that performed the same task,
> and letting natural selection decide which one survived.
>
> For example, at
> "http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/;
> Jay Pipes said that being under the big tent should not mean that the
> project is the only/best way to provide a specific function to OpenStack
> users.
>
> On the other hand, the OpenStack new projects requirements *do*
> explicitly state that "Where it makes sense, the project cooperates with
> existing projects rather than gratuitously competing or reinventing the
> wheel."
>
> Maybe it boils down to the definition of "gratuitous" competition.

For the record I think I've always been clear that I don't see
competition as a bad thing within the OpenStack ecosystem however I have
always been a proponent of having a *single consistent REST API* for a
particular service type. I think innovation should happen at the
implementation layer, but the public HTTP APIs should be collated and
reviewed for overlap and inconsistencies.

This was why in the past I haven't raised a stink about multiple
deployment tools, since there was no OpenStack HTTP API for deployment
of OpenStack itself. But I have absolutely raised concerns over overlap
of HTTP APIs, like is the case with Monasca and various Telemetry
project APIs. Again, implementation diversity cool. Public HTTP API
diversity, not cool.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off


On 07/27/2016 10:10 AM, Chris Friesen wrote:

On 07/27/2016 09:59 AM, Ed Leafe wrote:

On Jul 27, 2016, at 10:51 AM, Joshua Harlow 
wrote:


Whether to have competing projects in the big tent was debated by
the TC
at the time and my recollection is that we decided that was a good
thing
-- if someone wanted to develop a Nova replacement, then let them do it
in public with the community. It would either win or lose based on its
merits. Why is this not something which can happen here as well?


For real, I (or someone) can start a nova replacement without getting
rejected (or yelled at or ...) by the TC saying it's a competing
project??? Wow, this is news to me...


No, you can’t start a Nova replacement and still call yourself OpenStack.

The sense I have gotten over the years from the TC is that gratuitous
competition is strongly discouraged.


I seem to recall that back during the "big tent" discussion people were
talking about allowing competing projects that performed the same task,
and letting natural selection decide which one survived.

For example, at
"http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/;
Jay Pipes said that being under the big tent should not mean that the
project is the only/best way to provide a specific function to OpenStack
users.

On the other hand, the OpenStack new projects requirements *do*
explicitly state that "Where it makes sense, the project cooperates with
existing projects rather than gratuitously competing or reinventing the
wheel."

Maybe it boils down to the definition of "gratuitous" competition.


For the record I think I've always been clear that I don't see 
competition as a bad thing within the OpenStack ecosystem however I have 
always been a proponent of having a *single consistent REST API* for a 
particular service type. I think innovation should happen at the 
implementation layer, but the public HTTP APIs should be collated and 
reviewed for overlap and inconsistencies.


This was why in the past I haven't raised a stink about multiple 
deployment tools, since there was no OpenStack HTTP API for deployment 
of OpenStack itself. But I have absolutely raised concerns over overlap 
of HTTP APIs, like is the case with Monasca and various Telemetry 
project APIs. Again, implementation diversity cool. Public HTTP API 
diversity, not cool.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On Jul 27, 2016, at 12:10 PM, Chris Friesen  wrote:

> Maybe it boils down to the definition of "gratuitous" competition.

Precisely, which is why we have humans and not computer algorithms to decide 
these things.

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] glance developers and operators midcycle sync -- recordings

Hi all,


We'd a midcycle sync last month with the glance development team and
operators team where different individuals from across varied time zones
participated. While the scheduling was a challenge and some had to join
too early or too late, the event was pretty successful. We'd a ton of
productive discussions for the first time event of such nature. I hope
that we will continue to keep this collaboration going and maintain a
cadence between development and operators.


Thanks to Kris for letting us use a tool that let's recordings possible.
I've managed to trans-code the audio/visual into a youtube video with
the chat transcripts posted as a paste in the description there.


The audio/video recording is available at:
_https://youtu.be/DuSvm92iscM_

Chat transcript available at:   http://paste.openstack.org/show/542469/




Please find the full details of the event including notes on the various
topics at:
https://etherpad.openstack.org/p/newton-glance-and-ops-midcycle-sync


As always, feel free to reach out if any questions or comments. Cheers!

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] Questions regarding Kuryr

2016-07-27 Thread Vikas Choudhary

Hi Amir,

Thank You for showing interest in Kuryr!!!

One simple approach could be:
1> Have neutron and keystone running.
2> git clone kuryr-libnetwork repo
 and follow Readme
instructions to install kuryr.

Hope this helps. If you still face issues, please feel free to reach out to
us on irc channel, #openstack-kuryr

Thanks & Regards
Vikas

On Wed, Jul 27, 2016 at 10:21 PM, Amir, Shai  wrote:

> Hi,
>
>
>
> I saw that you are one of the leading contributors to Kuryr and was
> wondering if you can point me to the right direction.
>
> I am trying to get Kuryr working on a simple mitaka based devstack install
> along with docker.
>
>
>
> Any pointers to how to get this installed and working will be highly
> appreciated.
>
>
>
> Best regards,
>
> Shai
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-27 Thread Chris Friesen


On 07/27/2016 09:59 AM, Ed Leafe wrote:

On Jul 27, 2016, at 10:51 AM, Joshua Harlow  wrote:


Whether to have competing projects in the big tent was debated by the TC
at the time and my recollection is that we decided that was a good thing
-- if someone wanted to develop a Nova replacement, then let them do it
in public with the community. It would either win or lose based on its
merits. Why is this not something which can happen here as well?


For real, I (or someone) can start a nova replacement without getting rejected 
(or yelled at or ...) by the TC saying it's a competing project??? Wow, this is 
news to me...


No, you can’t start a Nova replacement and still call yourself OpenStack.

The sense I have gotten over the years from the TC is that gratuitous 
competition is strongly discouraged.


I seem to recall that back during the "big tent" discussion people were talking 
about allowing competing projects that performed the same task, and letting 
natural selection decide which one survived.


For example, at 
"http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/; 
Jay Pipes said that being under the big tent should not mean that the project is 
the only/best way to provide a specific function to OpenStack users.


On the other hand, the OpenStack new projects requirements *do* explicitly state 
that "Where it makes sense, the project cooperates with existing projects rather 
than gratuitously competing or reinventing the wheel."


Maybe it boils down to the definition of "gratuitous" competition.

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] [glare] Glance virtual midcycle recordings

Hi all,


The Glance virtual midcycle was last month and we were able to record
the event and write meeting notes. Please see the "Recordings" (line 30
now) sub-title for audio/visual updates and meeting notes at the near
bottom of the etherpad linked below.


https://etherpad.openstack.org/p/newton-glance-virtual-midcycle


There have been some noted instances where people either inadvertently
or otherwise have updated the etherpad, thus removing the text. Please
be considerate and watchful of your keyboard when keeping the etherpad open.

But for the record, here's the content/links that can be accessed if you
are not a fan of the etherpad colors.

Recordings:
 
* Day 1 Recording (MP4) (143MB) - Download from
https://dl.dropboxusercontent.com/s/f5syv2d1gyjh8lm/GlanceVirtualMidcycleDay1.mp4
* Day 2 Glance Newton Midcycle Meetup - Glare
API _https://youtu.be/FgbgiaAFGxE_
* Day 2 GlanceSpecs discussionhttps://youtu.be/feiORKFiMI0

More permanent location of the meeting details:
http://paste.openstack.org/show/542667/

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] tripleo-test-cloud-rh2 local mirror server

2016-07-27 Thread Paul Belanger

On Wed, Jul 27, 2016 at 02:54:00PM +0100, Derek Higgins wrote:
> On 21 July 2016 at 23:04, Paul Belanger  wrote:
> > Greetings,
> >
> > I write today to see how I can remove this server from 
> > tripleo-test-cloud-rh2. I
> > have an open patch[1] currently to migrate tripleo-ci to use our AFS 
> > mirrors for
> > centos and epel.  However, I'm still struggling to see what else you are 
> > using
> > the local mirror for.
> >
> > From what I see, there appears to be some puppet modules in the mirror?
> >
> > The reason I am doing this work, is to help bring tripleo inline with
> > openstack-infra tooling.  There shouldn't be the need for a project to 
> > maintain
> > its own infrastructure outside of openstack-infra.  If so, I see that as 
> > some
> > sort of a failure between the project and openstack-infra.   And with that 
> > in
> > mind, I am here to help fix that.
> >
> > For the most part, I think we have everything currently in place to migrate 
> > away
> > from your locally mirror. I just need some help figuring what else is left 
> > and
> > then delete it.
> 
> Hi Paul,
> The mirror server hosts 3 sets of data used in CI long with a cron
> a job aimed at promoting trunk repositories,
> The first you've already mentioned, there is a list of puppet modules
> hosted here, we soon hope to move to packaged puppet modules so the
> need for this will go away.
> 
Ya, I was looking at an open review to rework this. If we moved these puppet
modules to tarballs over git repos, I think we could mirror them pretty easy
into our AFS mirrors.  Them being git repos requires more work because some
policies around git repos.

> The second is a mirror of the centos cloud images, these are updated
> hourly by the centos-cloud-images cronjob[1], I guess these could be
> easily replaced with the AFS server
> 
So 2 things here.

1) I've reached out to CentOS asking to enable rsync support on
http://cloud.centos.org/ if they do that, I can easily enable rsync for it.

2) What about moving away from the centos diskimage-builder element and switch
to centos-minimal element. I have an open review for this, but need help on
actually testing this.  It moves away from using the cloud image, and instead
uses yumdownloader to prebuild the images.

> Then we come to the parts where it will probably be more tricky to
> move away from our own server
> 
> o cached images - our nightly periodic jobs run tripleo ci with
> master/HEAD for all openstack projects (using the most recent rdo
> trunk repository), if the jobs pass then we upload the overcloud-full
> and ipa images to the mirror server along with logging what jobs
> passed, this happens at the end of toci_instack.sh[2], nothing else
> happens at this point the files are just uploaded nothing starts using
> them yet.
> 
I suggest we move this to tarballs.o.o for now, this is what other projects are
doing.  I believe we are also considering moving this process into AFS too.

> o promote script - hourly we then run the promote script[3], this
> script is whats responsible for the promotion of the master rdo
> repository that is used by tripleo ci (and devs), it checks to see if
> images have been updated to the mirror server by the periodic jobs,
> and if all of the jobs we care about (currently
> periodic-tripleo-ci-centos-7-ovb-ha
> periodic-tripleo-ci-centos-7-ovb-nonha[4]) passed then it does 2
> things
>   1. updates the current-tripleo link on the mirror server[5]
>   2. updates the current-tripleo link on the rdo trunk server[6]
> By doing this we ensure that the the current-tripleo link on the rdo
> trunk server is always pointing to something that has passed tripleo
> ci jobs, and that tripleo ci is using cached images that were built
> using this repository
> 
Okay, I think we need to dive more into this. It might be possible to make this
a post job or use mirror-update.openstack.org

> We've had to run this promote script on the mirror server as the
> individual jobs run independently and in oder to make the promote
> decision we needed somewhere that is aware of the status of all the
> jobs
> 
> Hope this answers your questions,
> Derek.
> 
> [1] - 
> http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/scripts/mirror-server/mirror-server.pp#n40
> [2] - 
> http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/toci_instack.sh#n198
> [3] - 
> http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/scripts/mirror-server/promote.sh
> [4] - 
> http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/scripts/mirror-server/mirror-server.pp#n51
> [5] - http://8.43.87.241/builds/current-tripleo/
> [6] - 
> http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-master-tripleo/
> 
> >
> > [1] https://review.openstack.org/#/c/326143/
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:

[openstack-dev] [glance] [glance_store] Removing the S3 driver

Hi all,


Just wanted to follow up on the deprecation of S3 driver that Flavio
started [1], we are now in the phase of removing the S3 driver from
glance_store tree [2]. I've added some documentation to the release
notes but have a feeling that operators may be using more than that to
read up on glance_store updates. This was discussed a bit during the
glance-operators sync last month [3] too.


The plan is to release store as soon as this [2] review merges and after
currently proposed glance_store v0.15.0 release is out & tested on
glance gate. For now, the tentative release date with this change is
sometime mid-next-week so that this happens in Newton time-frame.


Either way, I just wanted to give a quick heads up and see if I should
be doing more courtesy additions, doc updates, etc. towards this.
Reviews on the proposal are welcome for the feedback as well.


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

[2] https://review.openstack.org/#/c/347620/

[3] https://etherpad.openstack.org/p/newton-glance-and-ops-midcycle-sync


Cheers,

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [UI] Version

2016-07-27 Thread Ben Nemec

On 07/27/2016 11:13 AM, Dougal Matthews wrote:
> 
> 
> On Wednesday, 27 July 2016, Steven Hardy  > wrote:
> 
> On Wed, Jul 27, 2016 at 02:08:08PM +0100, Dougal Matthews wrote:
> >On 27 July 2016 at 12:41, Honza Pokorny  > wrote:
> >
> >  Hello folks,
> >
> >  As the tripleo-ui project is quickly maturing, it might be
> time to start
> >  versioning our code.Â  As of now, the version is set to 0.0.1
> and that
> >  hardly reflects the state of the project.
> >
> >  What do you think?
> >
> >Yup, Sounds good to me! I would suggest that we make the Newton
> >release 1.0 and then continue from there. I am not sure what the
> >normal pattern is tho'
> 
> No, please don't invent an independent versioning scheme.  tripleo UI
> should be a tripleo deliverable, and part of the coordinated release
> (see
> my reply to Honza).
> 
> 
> Aha, sorry, I must have misunderstood how things are handled generally.
> I was remembering how tripleoclient was first versioned. Is there a
> document somewhere coving the process? All I can find is the release
> management wiki page.

We should be following semver: http://semver.org/

I don't know that tagging Newton as 1.0 would necessarily be wrong, it
just means we're committing to a stable API at that point (whatever that
means for the UI).

>  
> 
> 
> Thanks!
> 
> Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Support for volume sharing across multiple VM's

2016-07-27 Thread Adam Lawson

I heard there's been some attention given to and progress made supporting
sharing a single volume with multiple VM's. Where are we along the
development curve and has anyone been able to get this to work?

Thanks!

//adam

*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

2016-07-27 Thread Devdatta Kulkarni

Hi Sudipta,

There is another approach you can consider which does not need any changes to 
Nova.

The approach works as follows:
- Save the container image tar in Swift
- Generate a Swift tempURL for the container file
- Boot Nova vm and pass instructions for following steps through cloud init / 
user data
  - download the container file from Swift (wget)
  - load it (docker load)
  - run it (docker run)

We have implemented this approach in Solum (where we use Heat for deploying a 
VM and
then run application container on it  by providing above instructions through 
user_data of the HOT).

Thanks,
Devdatta


-


From: Sudipta Biswas 
Sent: Wednesday, July 27, 2016 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt
  
Premise:

While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel for 
multiple containers.
- They already have a significant investment (including skills) in OpenStack's 
Virtual Machine workflow and would like to re-use it as much as possible.
- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers workflows 
which already tries to address the first point. But we wanted to arrive at an 
approach that addresses all the above three in context of OpenStack Nova with 
minimalist changes.


Design Considerations:

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.

The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum operating 
system required to run it.
The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the community 
before proposing this as a spec or blueprint.


Approach 1

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in glance were 
a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual machine.

Following are some of the changes to the OpenStack code that implements this 
approach:

1. Define a new conf parameter in nova called – 
base_vm_image=/var/lib/libvirt/images/baseimage.qcow2
This option is used to specify the base VM image.

2. define a new sub_virt_type = container in nova conf. Setting this parameter 
will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type – this workflow will not work at this 
moment.

3. In the virt/libvirt/driver.py we do the following based on the sub_virt_type 
= container:

- We create a qcow2 disk from the base_vm_image and expose that 'disk' as the 
boot disk for the virtual machine.
 Note – this is very similar to a regular virtual machine boot minus the fact 
that the image is not downloaded from
glance but instead it is present on the host.


- We download the docker image into the /var/lib/nova/instances/_base directory 
and then for each new virtual machine boot – we create a new directory 
/var/lib/nova/instances/ as it's and copy the docker filesystem 
to it. Note – there are subsequent improvements to this idea that could be 
performed around the lines of using a union filesystem approach.
- The step above allows each virtual machine to have a different copy of the 
filesystem.
- We create a 'passthrough' mount of the filesystem via libvirt. This code is 
also present in the nova libvirt driver and we just trigger it based on our 
sub_virt_type parameter.

4. A cloud init – userdata is provided that looks somewhat like this:

runcmd:
  - mount -t 9p -o trans=virtio share_dir /mnt
  - chroot /mnt /bin/

The command_to_run is usually the entrypoint to for the docker image.

There could be better approaches to determine the entrypoint as well (say from 
docker image metadata).


Approach 2.

In this approach, the workflow remains the same as the first one with the 
exception that the
docker image is changed into a qcow2 image using a tool like virt-make-fs 
before uploading it to glance, instead of a tar file.

A tool like virt-make-fs can convert a tar file to a qcow2 image very easily.

This image is then downloaded on the compute node and a qcow2 disk is 
created/attached to the virtual machine that boots using the base_vm_image.


Approach 3

A custom qcow2 image is created using kernel, initramfs and the docker image 
and uploaded to glance.  No changes are needed in openstack nova. It boots as a 
regular VM.

Changes will be needed in image generation tools and will involve few 
additional tasks from an operator point of view.


I look forward to your comments/suggestions on the above.


Thanks,
Sudipto

[openstack-dev] [glance] [oslo] configs help text for glance_store

Hi all,


There was a intricate issue [1] when using help text with additive
strings for translations, when passed through oslo.config. The error
could not be seen on your local test environment or on glance_store docs
visibly as it reflected only on glance docs gate. (Well, unless you
tested the latest of glance_store with glance before commit/review.)


Thanks to Doug Hellmann, a solution for this has been proposed [2] for
that issue. However, until the next release and subsequent sync of
oslo.config in glance, I sincerely advice all the glance core reviews,
glance_store driver maintainers and all other respective individuals to
refrain from merging any help texts that have such 'additive strings'.


This may have an adverse effect on the glance gate and on further
releases of glance_store in Newton in this release critical period.
Also, note that the 0.14.0 release of glance_store had to be pinned down
[3] [4] and I've proposed a short release for the store lib 0.15.0 [5]
that will help us evaluate store ;  propose  & review changes therein in
a informed manner.


For those working on improving help text, I request you to test your
latest changes the way Doug has described testing oslo.config change in
a comment on PS1 here [2]. Please leave a comment on your review once
you have tested your config help text changes as such and help the
reviewers save time by allowing them to 'not' do the same locally for
every help text change proposed.


Hope that the severity of the issue, message and intent is clear to all
the audience concerned. If not, please feel free to reach out. Let's all
make sure we progress through the review queue in the most important
phase of the release cycle.


[1] https://bugs.launchpad.net/oslo.config/+bug/1605648

[2] https://review.openstack.org/#/c/347907/

[3] https://bugs.launchpad.net/glance-store/+bug/1606746

[4]
http://lists.openstack.org/pipermail/openstack-docs/2016-July/008910.html

[5] https://review.openstack.org/#/c/347621/

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

On Wed, Jul 27, 2016 at 08:41:17AM -0500, Matthew Thode wrote:
> We've started a period of self nomination in preparation for the
> requirements project fully moving into project (as it's still under Doug
> Hellmann).
> 
> We are gathering the self nominations here before we vote next week.
> https://etherpad.openstack.org/p/requirements-ptl-newton
> 
> Nominees should also send an email to the openstack-dev list.

I'd like to nominate for PTL of the, to be formed, requirements project.

For as long as I've been working on OpenStack the requirements data, code and
process has been managed as a sort of sub-team of release management with
strong overlaps to the stable branch team(s).  The workload has grown to the
point it needs it's own team with a PTL to manage priorities and reduce the
cross project pain points.

I feel like I understand the role of the requirements team and have advocated
that the requirements team should be more active in cross project issues.

The requirements team, like probably every other team, has a lot of debt.
We've worked hard to reduce that since Austin and I see that in the near future
we'll be able to tackle some of the bigger problems.

In rough priority order:
 - Improving communication, often decisions are made in the requirements team
   that affect many projects, I have a commitment to bringing more experts in
   for strategic reviews/discussions
 - cross-project testing for upper-constraints changes.  Once this is done
   it'll make breakage, like the recent oslo.context one, much harder to hit.
 - Work closely with the release managers as there is still a lot of common
   issues there.  In that a release of $project will trigger processes in the
   requirements team.
 - Getting openstack_requirements *code* to the point it can be installed as a
   library.  We've seen issues in the past where stable branches need largish
   backports to work correctly.  Really the *code* and *data* should be treated
   independently

I suspect that if you look at the review statistics for the requirements repo
I'm much lower than many of the core team.

I believe I'm eligible for nomination due to any of the following reviews.

https://review.openstack.org/#/q/project:openstack/requirements+status:merged+owner:tonyb+after:2016-04-07

IRC: tonyb

Yours Tony.

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Sorry, missed part of this.

I do not believe there is overlap between openstack-ansible which uses lxc 
containerization with thick containers and kolla which uses docker/kubernetes 
with thin containers. These are architecturally very different things and to 
reference my other email, there are technical reasons for doing things each way.

The Fuel CCP case is different, in that it is doing the same technical thing as 
kolla. kubernetes managed, docker based thin containers.

Thanks,
Kevin


From: Michael Still [mi...@stillhq.com]
Sent: Wednesday, July 27, 2016 5:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On Tue, Jul 26, 2016 at 4:44 PM, Fox, Kevin M 
> wrote:

[snip]

The issue is, as I see it, a parallel activity to one of the that is currently 
accepted into the Big Tent, aka Containerized Deployment

[snip]

This seems to be the crux of the matter as best as I can tell. Is it true to 
say that the concern is that Kolla believes they "own" the containerized 
deployment space inside the Big Tent?

Whether to have competing projects in the big tent was debated by the TC at the 
time and my recollection is that we decided that was a good thing -- if someone 
wanted to develop a Nova replacement, then let them do it in public with the 
community. It would either win or lose based on its merits. Why is this not 
something which can happen here as well?

I guess I should also point out that there is at least one other big tent 
deployment tool deploying containerized openstack components now, so its not 
like this idea is unique or new. Perhaps using kubernetes makes it different 
somehow, but I don't see it.

Michael




--
Rackspace Australia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [UI] Version

2016-07-27 Thread Dougal Matthews

On Wednesday, 27 July 2016, Steven Hardy  wrote:

> On Wed, Jul 27, 2016 at 02:08:08PM +0100, Dougal Matthews wrote:
> >On 27 July 2016 at 12:41, Honza Pokorny  > wrote:
> >
> >  Hello folks,
> >
> >  As the tripleo-ui project is quickly maturing, it might be time to
> start
> >  versioning our code.Â  As of now, the version is set to 0.0.1 and
> that
> >  hardly reflects the state of the project.
> >
> >  What do you think?
> >
> >Yup, Sounds good to me! I would suggest that we make the Newton
> >release 1.0 and then continue from there. I am not sure what the
> >normal pattern is tho'
>
> No, please don't invent an independent versioning scheme.  tripleo UI
> should be a tripleo deliverable, and part of the coordinated release (see
> my reply to Honza).


Aha, sorry, I must have misunderstood how things are handled generally. I
was remembering how tripleoclient was first versioned. Is there a document
somewhere coving the process? All I can find is the release management wiki
page.


>
> Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] repo split

2016-07-27 Thread Ryan Hallisey

Agreed, it's been a week. The vote can be brought up again when
the conclusion of N is closer.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, July 27, 2016 11:46:44 AM
Subject: Re: [openstack-dev] [kolla] repo split

Martin,

Thanks for your feedback.  This vote has expired without a consensus.  I
think we need to try a new vote once the core team gets comfortable with
the backporting process I spoke about earlier in a different thread this
vote would likely pass.

Regards
-steve

On 7/27/16, 3:09 AM, "Martin André"  wrote:

>On Thu, Jul 21, 2016 at 5:21 PM, Steven Dake (stdake) 
>wrote:
>> I am voting -1 for now, but would likely change my vote after we branch
>> Newton.  I'm not a super big fan of votes way ahead of major events
>>(such
>> as branching) because a bunch of things could change between now and
>>then
>> and the vote would be binding.
>>
>> Still community called the vote - so vote stands :)
>
>IIUC, if split there is, it's scheduled for when we branch out Newton
>which is only 1 month ahead.
>
>I'm +1 on splitting ansible deployment code into kolla-ansible.
>
>Martin
>
>> Regards
>> -steve
>>
>>
>> On 7/20/16, 1:48 PM, "Ryan Hallisey"  wrote:
>>
>>>Hello.
>>>
>>>The repo split discussion that started at summit was brought up again at
>>>the midcycle.
>>>The discussion was focused around splitting the Docker containers and
>>>Ansible code into
>>>two separate repos [1].
>>>
>>>One of the main opponents to the split is backports.  Backports will
>>>need
>>>to be done
>>>by hand for a few releases.  So far, there hasn't been a ton of
>>>backports, but that could
>>>always change.
>>>
>>>As for splitting, it provides a much clearer view of what pieces of the
>>>project are where.
>>>Kolla-ansible with its own repo will sit along side kolla-kubernetes as
>>>consumers of the
>>>kolla repo.
>>>
>>>The target for the split will be for day 1 of Occata. The core team will
>>>vote on
>>>the change of splitting kolla into kolla-ansible and kolla.
>>>
>>>Cores please respond with a +1/-1 to approve or disapprove the repo
>>>split. Any community
>>>member feel free to weigh in with your opinion.
>>>
>>>+1
>>>-Ryan
>>>
>>>[1] - https://etherpad.openstack.org/p/kolla-N-midcycle-repo-split
>>>
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] mascot/logo ideas

2016-07-27 Thread Gui Maluf

Wolf? it's so overrated
+1 for tardigrade


On Wed, Jul 27, 2016 at 12:39 PM, Emilien Macchi  wrote:

> On Wed, Jul 27, 2016 at 10:55 AM, David Moreau Simard 
> wrote:
> > What's even the relation between a wolf and puppet ?
>
>
> https://www.thegiftexperience.co.uk/cms_media/images/600x1000_fitbox-wolf_puppet_a.jpg
>
> That's the only thing I found on the Internet.
>
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> >
> > On Jul 27, 2016 9:36 AM, "Emilien Macchi"  wrote:
> >>
> >> Looking at the poll we have 4 votes for the wolf, I guess we can go
> >> with it. Tardigrade looses by 2 votes.
> >>
> >> If anyone is against this vote please raise your hand now :-)
> >>
> >> On Tue, Jul 26, 2016 at 4:26 PM, Emilien Macchi 
> >> wrote:
> >> > We have 6 votes in total, results are:
> >> >
> >> > 2 votes for wolf.
> >> > 2 votes for  tardigrade - https://en.wikipedia.org/wiki/Tardigrade
> >> > 1 vote for axolotl - https://en.wikipedia.org/wiki/Axolotl
> >> > 1 vote for dog puppet:
> >> > https://img1.etsystatic.com/000/0/5613081/il_fullxfull.241000707.jpg
> >> >
> >> > Sounds like we haven't reached a consensus and failed to get more
> >> > votes... I would propose to either report our vote or cancel and
> >> > choose no mascot.
> >> > Thoughts?
> >> >
> >> > On Mon, Jul 25, 2016 at 10:27 PM, Emilien Macchi 
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> So we have until July 27th to take the decision about our mascot.
> >> >> If you are interested to vote, please add +1 on the proposals on the
> >> >> etherpad [1].
> >> >>
> >> >> By Wednesday, we'll take the one with the most of +1
> >> >>
> >> >> Thanks,
> >> >>
> >> >> [1] https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
> >> >>
> >> >> On Tue, Jul 12, 2016 at 11:23 AM, Emilien Macchi  >
> >> >> wrote:
> >> >>> Hey,
> >> >>>
> >> >>> During the meeting we decided to use etherpad to submit new ideas
> for
> >> >>> our mascot / logo [1]:
> >> >>> https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
> >> >>>
> >> >>> Feel free to use your imagination as long you stay SFW :-)
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> [1] http://osdir.com/ml/openstack-dev/2016-07/msg00456.html
> >> >>> --
> >> >>> Emilien Macchi
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Emilien Macchi
> >> >
> >> >
> >> >
> >> > --
> >> > Emilien Macchi
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
*guilherme* \n
\t *maluf*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On Jul 27, 2016, at 10:51 AM, Joshua Harlow  wrote:

>> Whether to have competing projects in the big tent was debated by the TC
>> at the time and my recollection is that we decided that was a good thing
>> -- if someone wanted to develop a Nova replacement, then let them do it
>> in public with the community. It would either win or lose based on its
>> merits. Why is this not something which can happen here as well?
> 
> For real, I (or someone) can start a nova replacement without getting 
> rejected (or yelled at or ...) by the TC saying it's a competing project??? 
> Wow, this is news to me...

No, you can’t start a Nova replacement and still call yourself OpenStack.

The sense I have gotten over the years from the TC is that gratuitous 
competition is strongly discouraged. When the Monasca project was being 
considered for the big tent, there was a *lot* of concern expressed over the 
partial overlap with Ceilometer. It was only after much reassurance that the 
overlap was not fundamental that these objections were dropped.

I have no stake in either Fuel or Kolla, so my only concern is duplication of 
effort. You can always achieve more working together, though it will never 
happen as fast as when you go it alone. It’s a trade-off: the needs of the 
vendor vs. the health of the community.

-- Ed Leafe

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-27 Thread Joshua Harlow


Michael Still wrote:

On Tue, Jul 26, 2016 at 4:44 PM, Fox, Kevin M > wrote:

[snip]

The issue is, as I see it, a parallel activity to one of the that is
currently accepted into the Big Tent, aka Containerized Deployment


[snip]

This seems to be the crux of the matter as best as I can tell. Is it
true to say that the concern is that Kolla believes they "own" the
containerized deployment space inside the Big Tent?

Whether to have competing projects in the big tent was debated by the TC
at the time and my recollection is that we decided that was a good thing
-- if someone wanted to develop a Nova replacement, then let them do it
in public with the community. It would either win or lose based on its
merits. Why is this not something which can happen here as well?


For real, I (or someone) can start a nova replacement without getting 
rejected (or yelled at or ...) by the TC saying it's a competing 
project??? Wow, this is news to me...




I guess I should also point out that there is at least one other big
tent deployment tool deploying containerized openstack components now,
so its not like this idea is unique or new. Perhaps using kubernetes
makes it different somehow, but I don't see it.

Michael




--
Rackspace Australia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][nova] Indivisible Resource Providers

On Jul 27, 2016, at 9:48 AM, Sam Betts (sambetts)  wrote:

> While discussing the proposal to add resource_class’ to Ironic nodes for 
> interacting with the resource provider system in Nova with Jim on IRC, I 
> voiced my concern about having a resource_class per node. My thoughts were 
> that we could achieve the behaviour we require by every Ironic node resource 
> provider having a "baremetal" resource class of which they can own a maximum 
> of 1. Flavor’s that are required to land on a baremetal node would then 
> define that they require at least 1 baremetal resource, along with any other 
> resources they require.

I was going to respond pointing out the issues with that approach, but then the 
rest of your email did just that. :)

I strongly preferred the approach that each particular hardware configuration 
would be a class, so that if you had 50 nodes with configuration A, and 20 
nodes with configuration B, that that would be reflected in two resource 
classes, with corresponding inventories to match the nodes. When a node is 
provisioned, that inventory is decremented. This would be much more consistent 
with the rest of the resource provider design, as having many, many classes all 
of which represent identical hardware seems backwards.

-- Ed Leafe

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

2016-07-27 Thread Hongbin Lu

Unfortunately, this doesn't seem to fit into Magnum as well. According to the 
current mission statement [1], Magnum is for provisioning, scaling, and 
managing Container Orchestration Engines (i.e. Kubernetes), so managing 
containers in VM is not consistent with Magnum's mission.

It seems there is a misconception that Magnum is the home for containers in 
OpenStack, so all the container use cases were pushed to Magnum. However, this 
is not true because Magnum also has its scope and cannot support anything that 
goes beyond.

[1] 
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2128

Best regards,
Hongbin

From: Maxime Belanger [mailto:mbelan...@internap.com]
Sent: July-27-16 10:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][rfc] Booting docker images using nova 
libvirt


In my opinion,



You are loosing so much advantages of the what a container platform already 
offer.



Example (not exhaustive):

  1.  Glance is becoming your "Image Registry"

 *   No incremental pull
 *   No image layer caching
 *   Decrease in speed
 *   You have to convert from a Container image to a qcow2 image format 
(loosing time here and not imcremental)

  1.  One container per VM is exactly identical as having one service per VM

 *   Only advantage is that your deployment recipes are less complicated

  1.  Scaling the app

 *   Having to use Heat to scale a container (actually a vm).
I understand why your client are asking for this as we are (as a first step) 
doing one container per VM because our deployment architecture is not yet ready 
for full container stack. But There is other way of doing what your client is 
asking without implementing anything in Nova.
That said, there is Magnum project to support containers in an Openstack 
environment.

Quite frankly, I am not sure nova should deal with containers as I do not see 
the link with current Nova responsibilities.

Regards,
Max

From: Sudipta Biswas 
>
Sent: July 27, 2016 10:17:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt


Premise:

While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel for 
multiple containers.
- They already have a significant investment (including skills) in OpenStack's 
Virtual Machine workflow and would like to re-use it as much as possible.
- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers workflows 
which already tries to address the first point. But we wanted to arrive at an 
approach that addresses all the above three in context of OpenStack Nova with 
minimalist changes.


Design Considerations:

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.

The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum operating 
system required to run it.

The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the community 
before proposing this as a spec or blueprint.


Approach 1

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in glance were 
a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual machine.

Following are some of the changes to the OpenStack code that implements this 
approach:

1. Define a new conf parameter in nova called - 
base_vm_image=/var/lib/libvirt/images/baseimage.qcow2
This option is used to specify the base VM image.

2. define a new sub_virt_type = container in nova conf. Setting this parameter 
will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type - this workflow will not work at this 
moment.

3. In the virt/libvirt/driver.py we do the following based on the sub_virt_type 
= container:

- We create a qcow2 disk from the base_vm_image and expose that 'disk' as the 
boot disk for the virtual machine.
 Note - this is very similar to a regular virtual machine boot minus the fact 
that the image is not downloaded from
glance but instead it is present on the host.



- We download the docker image into the /var/lib/nova/instances/_base directory 
and then for each new virtual machine boot - we create a new directory 
/var/lib/nova/instances/ as it's and copy the docker filesystem 
to it. Note - there are subsequent improvements to this idea that could be 
performed around the lines of using a union filesystem approach.

- The step above

Re: [openstack-dev] [kolla] repo split

2016-07-27 Thread Steven Dake (stdake)

Martin,

Thanks for your feedback.  This vote has expired without a consensus.  I
think we need to try a new vote once the core team gets comfortable with
the backporting process I spoke about earlier in a different thread this
vote would likely pass.

Regards
-steve

On 7/27/16, 3:09 AM, "Martin André"  wrote:

>On Thu, Jul 21, 2016 at 5:21 PM, Steven Dake (stdake) 
>wrote:
>> I am voting -1 for now, but would likely change my vote after we branch
>> Newton.  I'm not a super big fan of votes way ahead of major events
>>(such
>> as branching) because a bunch of things could change between now and
>>then
>> and the vote would be binding.
>>
>> Still community called the vote - so vote stands :)
>
>IIUC, if split there is, it's scheduled for when we branch out Newton
>which is only 1 month ahead.
>
>I'm +1 on splitting ansible deployment code into kolla-ansible.
>
>Martin
>
>> Regards
>> -steve
>>
>>
>> On 7/20/16, 1:48 PM, "Ryan Hallisey"  wrote:
>>
>>>Hello.
>>>
>>>The repo split discussion that started at summit was brought up again at
>>>the midcycle.
>>>The discussion was focused around splitting the Docker containers and
>>>Ansible code into
>>>two separate repos [1].
>>>
>>>One of the main opponents to the split is backports.  Backports will
>>>need
>>>to be done
>>>by hand for a few releases.  So far, there hasn't been a ton of
>>>backports, but that could
>>>always change.
>>>
>>>As for splitting, it provides a much clearer view of what pieces of the
>>>project are where.
>>>Kolla-ansible with its own repo will sit along side kolla-kubernetes as
>>>consumers of the
>>>kolla repo.
>>>
>>>The target for the split will be for day 1 of Occata. The core team will
>>>vote on
>>>the change of splitting kolla into kolla-ansible and kolla.
>>>
>>>Cores please respond with a +1/-1 to approve or disapprove the repo
>>>split. Any community
>>>member feel free to weigh in with your opinion.
>>>
>>>+1
>>>-Ryan
>>>
>>>[1] - https://etherpad.openstack.org/p/kolla-N-midcycle-repo-split
>>>
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Competition is a good thing, when there are good, technical reasons for it. 
"The architecture of X just doesn't fit for my need Y". "Project X won't 
address my technical need, so I need to fork/spawn a new project Y to get a 
solution." I do not believe we're in this situation here.

If its just competition because developer X doesn't want to work with developer 
Y, thats fine too, provided that the community isn't paying for both.

Our collective resource is somewhat limited. We have a relatively static pool 
of gate resources, and infra folks. Nearing releases, those get particularly 
scarce/valuable. We all notice it during those times and if we are spending 
resource on needlessly competing things, thats bad. Why take the pain?

As I see it, right now Fuel CCP seems separate for political, not technical 
reasons and is consuming OpenStack community resource for what seems to be the 
benefit of only one company. Its fine that Fuel CCP exists. But I think either 
it should have its own non OpenStack infra, or commit to joining the Big Tent 
and we can debate if we want 2 basically identical things inside.

Thanks,
Kevin


From: Michael Still [mi...@stillhq.com]
Sent: Wednesday, July 27, 2016 5:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting 
Fuel CCP (docker/k8s) kicked off

On Tue, Jul 26, 2016 at 4:44 PM, Fox, Kevin M 
> wrote:

[snip]

The issue is, as I see it, a parallel activity to one of the that is currently 
accepted into the Big Tent, aka Containerized Deployment

[snip]

This seems to be the crux of the matter as best as I can tell. Is it true to 
say that the concern is that Kolla believes they "own" the containerized 
deployment space inside the Big Tent?

Whether to have competing projects in the big tent was debated by the TC at the 
time and my recollection is that we decided that was a good thing -- if someone 
wanted to develop a Nova replacement, then let them do it in public with the 
community. It would either win or lose based on its merits. Why is this not 
something which can happen here as well?

I guess I should also point out that there is at least one other big tent 
deployment tool deploying containerized openstack components now, so its not 
like this idea is unique or new. Perhaps using kubernetes makes it different 
somehow, but I don't see it.

Michael




--
Rackspace Australia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Modifying just a few values on overcloud redeploy

2016-07-27 Thread Steven Hardy

On Wed, Jul 27, 2016 at 11:04:22AM -0400, Adam Young wrote:
> On 07/27/2016 06:04 AM, Steven Hardy wrote:
> > On Tue, Jul 26, 2016 at 05:23:21PM -0400, Adam Young wrote:
> > > I worked through how to do a complete clone of the templates to do a
> > > deploy and change a couple values here:
> > > 
> > > http://adam.younglogic.com/2016/06/custom-overcloud-deploys/
> > > 
> > > However, all I want to do is to set two config options in Keystone.  
> > > Is
> > > there a simple way to just modify the two values below?  Ideally, just
> > > making a single env file and passing it via openstack overcloud 
> > > deploy -e
> > > somehow.
> > > 
> > > 'identity/domain_specific_drivers_enabled': value => 'True';
> > > 
> > > 'identity/domain_configurations_from_database': value => 'True';
> > Yes, the best way to do this is to pass a hieradata override, as documented
> > here:
> > 
> > http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_config.html
> > 
> > First step is to look at the puppet module that manages that configuration,
> > in this case I assume it's puppet-keystone:
> > 
> > https://github.com/openstack/puppet-keystone/tree/master/manifests
> > 
> > Some grepping shows that domain_specific_drivers_enabled is configured
> > here:
> > 
> > https://github.com/openstack/puppet-keystone/blob/master/manifests/init.pp#L1124..L1155
> > 
> > So working back from those variables, "using_domain_config" and
> > "domain_config_directory", you'd create a yaml file that looks like:
> > 
> > parameter_defaults:
> >ControllerExtraConfig:
> >  keystone::using_domain_config: true
> >  keystone::domain_config_directory: /path/to/config
> > 
> > However, it seems that you want to configure domain_specific_drivers_enabled
> > *without* configuring domain_config_directory, so that it comes from the
> > database?
> > 
> > In that case, puppet has a "passthrough" interface you can use (this is the
> > same for all openstack puppet modules AFAIK):
> > 
> > https://github.com/openstack/puppet-keystone/blob/master/manifests/config.pp
> > 
> > Environment (referred to as controller_extra.yaml below) file looks like:
> > 
> > parameter_defaults:
> >ControllerExtraConfig:
> >  keystone::config::keystone_config:
> >identity/domain_specific_drivers_enabled:
> >  value: true
> >identity/domain_configurations_from_database:
> >  value: true
> I'm assuming I can mix these two approaches, so that, if I need
> 
> keystone::using_domain_config: true
> 
> 
> 
> as well it would look like this:
> 
> parameter_defaults:
>   ControllerExtraConfig:
> keystone::using_domain_config: true
> keystone::config::keystone_config:
>   identity/domain_specific_drivers_enabled:
> value: true
>   identity/domain_configurations_from_database:
> value: true

Yes, but I think you'll need to remove the
domain_specific_drivers_enabled because that is already set to true via
using_domain_config (see my earlier puppet-keystone link)

So it would look like:

parameter_defaults:
  ControllerExtraConfig:
keystone::using_domain_config: true
keystone::config::keystone_config:
  identity/domain_configurations_from_database:
value: true

As previously mentioned, there appears to be some validation of
keystone::domain_config_directory when you enable
keystone::using_domain_config so you'll probably need to pass both.

> And over time,  if there is support put into the templates for the values,
> and we start seeing errors, we can just change from the latter  approach to
> the one you posted earlier?

Yes, this is possible, but it's been a cause of a few CI firedrills, so we
might consider just wiring in the needed interfaces to puppet-keystone now
when you figure out exactly what's required.

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] mascot/logo ideas

2016-07-27 Thread Emilien Macchi

On Wed, Jul 27, 2016 at 10:55 AM, David Moreau Simard  wrote:
> What's even the relation between a wolf and puppet ?

https://www.thegiftexperience.co.uk/cms_media/images/600x1000_fitbox-wolf_puppet_a.jpg

That's the only thing I found on the Internet.

> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Jul 27, 2016 9:36 AM, "Emilien Macchi"  wrote:
>>
>> Looking at the poll we have 4 votes for the wolf, I guess we can go
>> with it. Tardigrade looses by 2 votes.
>>
>> If anyone is against this vote please raise your hand now :-)
>>
>> On Tue, Jul 26, 2016 at 4:26 PM, Emilien Macchi 
>> wrote:
>> > We have 6 votes in total, results are:
>> >
>> > 2 votes for wolf.
>> > 2 votes for  tardigrade - https://en.wikipedia.org/wiki/Tardigrade
>> > 1 vote for axolotl - https://en.wikipedia.org/wiki/Axolotl
>> > 1 vote for dog puppet:
>> > https://img1.etsystatic.com/000/0/5613081/il_fullxfull.241000707.jpg
>> >
>> > Sounds like we haven't reached a consensus and failed to get more
>> > votes... I would propose to either report our vote or cancel and
>> > choose no mascot.
>> > Thoughts?
>> >
>> > On Mon, Jul 25, 2016 at 10:27 PM, Emilien Macchi 
>> > wrote:
>> >> Hi,
>> >>
>> >> So we have until July 27th to take the decision about our mascot.
>> >> If you are interested to vote, please add +1 on the proposals on the
>> >> etherpad [1].
>> >>
>> >> By Wednesday, we'll take the one with the most of +1
>> >>
>> >> Thanks,
>> >>
>> >> [1] https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
>> >>
>> >> On Tue, Jul 12, 2016 at 11:23 AM, Emilien Macchi 
>> >> wrote:
>> >>> Hey,
>> >>>
>> >>> During the meeting we decided to use etherpad to submit new ideas for
>> >>> our mascot / logo [1]:
>> >>> https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
>> >>>
>> >>> Feel free to use your imagination as long you stay SFW :-)
>> >>>
>> >>> Thanks,
>> >>>
>> >>> [1] http://osdir.com/ml/openstack-dev/2016-07/msg00456.html
>> >>> --
>> >>> Emilien Macchi
>> >>
>> >>
>> >>
>> >> --
>> >> Emilien Macchi
>> >
>> >
>> >
>> > --
>> > Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.4.0

2016-07-27 Thread Masayuki Igawa

Hi!

On Wed, Jul 27, 2016 at 11:50 PM, James E. Blair  wrote:
> Michał Dulko  writes:
>
>> Just wondering - were there tries to implement syntax highlighting in
>> diff view? I think that's the only thing that keeps me from switching to
>> Gertty.
>
> I don't know of anyone working on that, but I suspect it could be done
> using the pygments library.

Oh, it's an interesting feature to me :) I'll try to investigate and
implement in next couple of days :)

Thanks,
-- Masayuki Igawa

>
> -Jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] - Addition of Fuxi as a subproject

2016-07-27 Thread Gal Sagie

Hello everyone,

The following is a governance request to add project Fuxi as a storage
solution part
for Kuryr (part of Kuryr deliverable) [1]

I hope this can lead to other initiatives that want to work on drivers and
glue code that
connects containers orchestration engines and OpenStack projects.
(For example i believe a Keystone driver for Kubernetes can also be started
as a sub
project)

Please feel free to share your opinions/comments in the mailing list or in
the patch review.

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


Thanks
Gal.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] no neutron-lib meeting today

2016-07-27 Thread Henry Gessau

Myself and dougwig will be unable to attend today.
We'll resume as usual next week.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Modifying just a few values on overcloud redeploy

2016-07-27 Thread Adam Young


On 07/27/2016 06:04 AM, Steven Hardy wrote:

On Tue, Jul 26, 2016 at 05:23:21PM -0400, Adam Young wrote:

I worked through how to do a complete clone of the templates to do a
deploy and change a couple values here:

http://adam.younglogic.com/2016/06/custom-overcloud-deploys/

However, all I want to do is to set two config options in Keystone.  Is
there a simple way to just modify the two values below?  Ideally, just
making a single env file and passing it via openstack overcloud deploy -e
somehow.

'identity/domain_specific_drivers_enabled': value => 'True';

'identity/domain_configurations_from_database': value => 'True';

Yes, the best way to do this is to pass a hieradata override, as documented
here:

http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_config.html

First step is to look at the puppet module that manages that configuration,
in this case I assume it's puppet-keystone:

https://github.com/openstack/puppet-keystone/tree/master/manifests

Some grepping shows that domain_specific_drivers_enabled is configured
here:

https://github.com/openstack/puppet-keystone/blob/master/manifests/init.pp#L1124..L1155

So working back from those variables, "using_domain_config" and
"domain_config_directory", you'd create a yaml file that looks like:

parameter_defaults:
   ControllerExtraConfig:
 keystone::using_domain_config: true
 keystone::domain_config_directory: /path/to/config

However, it seems that you want to configure domain_specific_drivers_enabled
*without* configuring domain_config_directory, so that it comes from the
database?

In that case, puppet has a "passthrough" interface you can use (this is the
same for all openstack puppet modules AFAIK):

https://github.com/openstack/puppet-keystone/blob/master/manifests/config.pp

Environment (referred to as controller_extra.yaml below) file looks like:

parameter_defaults:
   ControllerExtraConfig:
 keystone::config::keystone_config:
   identity/domain_specific_drivers_enabled:
 value: true
   identity/domain_configurations_from_database:
 value: true

I'm assuming I can mix these two approaches, so that, if I need

keystone::using_domain_config: true



as well it would look like this:

parameter_defaults:
  ControllerExtraConfig:
keystone::using_domain_config: true
keystone::config::keystone_config:
  identity/domain_specific_drivers_enabled:
value: true
  identity/domain_configurations_from_database:
value: true


And over time,  if there is support put into the templates for the 
values, and we start seeing errors, we can just change from the latter  
approach to the one you posted earlier?

Note the somewhat idiosyncratic syntax, you pass the value via a
"value: foo" map, not directly to the configuration key (don't ask me why!)

Then do openstack overcloud deploy --templates /path/to/templates -e 
controller_extra.yaml

The one gotcha here is if puppet keystone later adds an explicit interface
which conflicts with this, e.g a domain_specific_drivers_enabled variable
in the above referenced init.pp, you will get a duplicate definition error
(because you can't define the same thing twice in the puppet catalog).

This means that long-term use of the generic keystone::config::keystone_config
interface can be fragile, so it's best to add an explicit e.g
keystone::domain_specific_drivers_enabled interface if this is a long-term
requirement.

This is probably something we should add to our docs, I'll look at doing
that.

Hope that helps,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] reminder to release libraries early and often

We're coming up on the feature and release freeze for libraries, and
quite a few of them have unreleased changes. Keep in mind that changes
to any branch of the library that are not included in a tagged release
are not being used in the functional or integration tests for server
projects, so the longer we wait to release them the less testing time we
have with them and the more risk we're building up.

Release liaisons, please review http://paste.openstack.org/show/542607/
for the list of unreleased changes of your libraries and prepare a
release for this week or next week.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

Excerpts from Matthew Thode's message of 2016-07-27 09:19:33 -0500:
> On 07/27/2016 09:07 AM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-07-27 08:41:17 -0500:
> >> We've started a period of self nomination in preparation for the
> >> requirements project fully moving into project (as it's still under Doug
> >> Hellmann).
> >>
> >> We are gathering the self nominations here before we vote next week.
> >> https://etherpad.openstack.org/p/requirements-ptl-newton
> >>
> >> Nominees should also send an email to the openstack-dev list.
> >>
> > 
> > Thanks for kicking this off, Matt! I'm looking forward to seeing this
> > team fully self-sufficient.
> > 
> > From the etherpad, I see a deadline set of August 5. Is that for
> > nominations, or the election to have an outcome?
> > 
> > For the record, Anita has agreed to be the primary election official,
> > and I will assist her.
> > 
> > Doug
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> That's for the self nomination period.  Immediately after that is when
> the election would be, we may vote in the meeting that day for just one
> of us to be put forward or do a normal election, I don't think we've
> clarified that yet.
> 

OK. We have some time to work that out, then.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] mascot/logo ideas

2016-07-27 Thread David Moreau Simard

What's even the relation between a wolf and puppet ?

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Jul 27, 2016 9:36 AM, "Emilien Macchi"  wrote:

> Looking at the poll we have 4 votes for the wolf, I guess we can go
> with it. Tardigrade looses by 2 votes.
>
> If anyone is against this vote please raise your hand now :-)
>
> On Tue, Jul 26, 2016 at 4:26 PM, Emilien Macchi 
> wrote:
> > We have 6 votes in total, results are:
> >
> > 2 votes for wolf.
> > 2 votes for  tardigrade - https://en.wikipedia.org/wiki/Tardigrade
> > 1 vote for axolotl - https://en.wikipedia.org/wiki/Axolotl
> > 1 vote for dog puppet:
> > https://img1.etsystatic.com/000/0/5613081/il_fullxfull.241000707.jpg
> >
> > Sounds like we haven't reached a consensus and failed to get more
> > votes... I would propose to either report our vote or cancel and
> > choose no mascot.
> > Thoughts?
> >
> > On Mon, Jul 25, 2016 at 10:27 PM, Emilien Macchi 
> wrote:
> >> Hi,
> >>
> >> So we have until July 27th to take the decision about our mascot.
> >> If you are interested to vote, please add +1 on the proposals on the
> >> etherpad [1].
> >>
> >> By Wednesday, we'll take the one with the most of +1
> >>
> >> Thanks,
> >>
> >> [1] https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
> >>
> >> On Tue, Jul 12, 2016 at 11:23 AM, Emilien Macchi 
> wrote:
> >>> Hey,
> >>>
> >>> During the meeting we decided to use etherpad to submit new ideas for
> >>> our mascot / logo [1]:
> >>> https://etherpad.openstack.org/p/puppet-openstack-mascot-logo
> >>>
> >>> Feel free to use your imagination as long you stay SFW :-)
> >>>
> >>> Thanks,
> >>>
> >>> [1] http://osdir.com/ml/openstack-dev/2016-07/msg00456.html
> >>> --
> >>> Emilien Macchi
> >>
> >>
> >>
> >> --
> >> Emilien Macchi
> >
> >
> >
> > --
> > Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Announcing Gertty 1.4.0

2016-07-27 Thread James E. Blair

Michał Dulko  writes:

> Just wondering - were there tries to implement syntax highlighting in
> diff view? I think that's the only thing that keeps me from switching to
> Gertty.

I don't know of anyone working on that, but I suspect it could be done
using the pygments library.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][nova] Indivisible Resource Providers

2016-07-27 Thread Sam Betts (sambetts)

While discussing the proposal to add resource_class' to Ironic nodes for 
interacting with the resource provider system in Nova with Jim on IRC, I voiced 
my concern about having a resource_class per node. My thoughts were that we 
could achieve the behaviour we require by every Ironic node resource provider 
having a "baremetal" resource class of which they can own a maximum of 1. 
Flavor's that are required to land on a baremetal node would then define that 
they require at least 1 baremetal resource, along with any other resources they 
require.  For example:

Resource Provider 1 Resources:
Baremetal: 1
RAM: 256
CPUs: 4

Resource Provider 2 Resources:
Baremetal: 1
RAM: 512
CPUs: 4

Resource Provider 3 Resources:
Baremetal: 0
RAM: 0
CPUs: 0

(Resource Provider 3 has been used, so it has zero resources left)

 Given the thought experiment it seems like this would work great with one 
exception, if you define 2 flavors:

Flavor 1 Required Resources:
Baremetal: 1
RAM: 256

Flavor 2 Required Resources:
Baremetal: 1
RAM: 512

Flavor 2 will only schedule onto Resource Provider 2 because it is the only 
resource provider that can provide the amount of resources required. However 
Flavor 1 could potentially end up landing on Resource Provider 2 even though it 
provides more RAM than is actually required. The Baremetal resource class would 
prevent a second node from ever being scheduled onto that resource provider, so 
scheduling more nodes doesn't result on 2 instance on the same node, but it is 
an inefficient use of resources.

To combat this inefficient use of resources, I wondered if it was possible to 
add a flag to a resource provider to define that it is an indivisible resource 
provider, which would prevent flavors that don't use up all the resources a 
provider provides from landing on that provider.

Sam


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

2016-07-27 Thread Maxime Belanger

In my opinion,


You are loosing so much advantages of the what a container platform already 
offer.


Example (not exhaustive):

  1.  Glance is becoming your "Image Registry"
 *   No incremental pull
 *   No image layer caching
 *   Decrease in speed
 *   You have to convert from a Container image to a qcow2 image format 
(loosing time here and not imcremental)
  2.  One container per VM is exactly identical as having one service per VM
 *   Only advantage is that your deployment recipes are less complicated
  3.  Scaling the app
 *   Having to use Heat to scale a container (actually a vm).

I understand why your client are asking for this as we are (as a first step) 
doing one container per VM because our deployment architecture is not yet ready 
for full container stack. But There is other way of doing what your client is 
asking without implementing anything in Nova.
That said, there is Magnum project to support containers in an Openstack 
environment.

Quite frankly, I am not sure nova should deal with containers as I do not see 
the link with current Nova responsibilities.

Regards,
Max


From: Sudipta Biswas 
Sent: July 27, 2016 10:17:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt


Premise:

While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel for 
multiple containers.
- They already have a significant investment (including skills) in OpenStack's 
Virtual Machine workflow and would like to re-use it as much as possible.
- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers workflows 
which already tries to address the first point. But we wanted to arrive at an 
approach that addresses all the above three in context of OpenStack Nova with 
minimalist changes.


Design Considerations:

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.

The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum operating 
system required to run it.

The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the community 
before proposing this as a spec or blueprint.


Approach 1

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in glance were 
a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual machine.

Following are some of the changes to the OpenStack code that implements this 
approach:

1. Define a new conf parameter in nova called – 
base_vm_image=/var/lib/libvirt/images/baseimage.qcow2
This option is used to specify the base VM image.

2. define a new sub_virt_type = container in nova conf. Setting this parameter 
will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type – this workflow will not work at this 
moment.

3. In the virt/libvirt/driver.py we do the following based on the sub_virt_type 
= container:

- We create a qcow2 disk from the base_vm_image and expose that 'disk' as the 
boot disk for the virtual machine.
 Note – this is very similar to a regular virtual machine boot minus the fact 
that the image is not downloaded from
glance but instead it is present on the host.


- We download the docker image into the /var/lib/nova/instances/_base directory 
and then for each new virtual machine boot – we create a new directory 
/var/lib/nova/instances/ as it's and copy the docker filesystem 
to it. Note – there are subsequent improvements to this idea that could be 
performed around the lines of using a union filesystem approach.

- The step above allows each virtual machine to have a different copy of the 
filesystem.

- We create a 'passthrough' mount of the filesystem via libvirt. This code is 
also present in the nova libvirt driver and we just trigger it based on our 
sub_virt_type parameter.

4. A cloud init – userdata is provided that looks somewhat like this:

runcmd:
  - mount -t 9p -o trans=virtio share_dir /mnt
  - chroot /mnt /bin/

The command_to_run is usually the entrypoint to for the docker image.

There could be better approaches to determine the entrypoint as well (say from 
docker image metadata).


Approach 2.

In this approach, the workflow remains the same as the first one with the 
exception that the
docker image is changed into a qcow2 image using a tool like virt-make-fs 
before uploading it to glance, instead of a tar file.

A tool like virt-make-fs can convert a tar file to a qcow2 image very easily.

This image is then

Re: [openstack-dev] [ptl][requirements] nomination period started

On Wed, Jul 27, 2016 at 10:07:20AM -0400, Doug Hellmann wrote:

> For the record, Anita has agreed to be the primary election official,
> and I will assist her.

Thanks Doug and Anita!

Yours Tony.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][requirements] nomination period started

2016-07-27 Thread Matthew Thode

On 07/27/2016 09:07 AM, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2016-07-27 08:41:17 -0500:
>> We've started a period of self nomination in preparation for the
>> requirements project fully moving into project (as it's still under Doug
>> Hellmann).
>>
>> We are gathering the self nominations here before we vote next week.
>> https://etherpad.openstack.org/p/requirements-ptl-newton
>>
>> Nominees should also send an email to the openstack-dev list.
>>
> 
> Thanks for kicking this off, Matt! I'm looking forward to seeing this
> team fully self-sufficient.
> 
> From the etherpad, I see a deadline set of August 5. Is that for
> nominations, or the election to have an outcome?
> 
> For the record, Anita has agreed to be the primary election official,
> and I will assist her.
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

That's for the self nomination period.  Immediately after that is when
the election would be, we may vote in the meeting that day for just one
of us to be put forward or do a normal election, I don't think we've
clarified that yet.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [daisycloud-core] About the new meeting channel

2016-07-27 Thread jason

Hi, team

Our meeting channel request has been approved:
https://review.openstack.org/#/c/346534/ .

So let's use the new channel for the coming irc meeting.


-- 
Yours,
Jason

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][rfc] Booting docker images using nova libvirt

2016-07-27 Thread Sudipta Biswas


*Premise:**
*
While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel 
for multiple containers.
- They already have a significant investment (including skills) in 
OpenStack's Virtual Machine workflow and would like to re-use it as much 
as possible.

- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers 
workflows which already tries to address the first point. But we wanted 
to arrive at an approach that addresses all the above three in context 
of OpenStack Nova with minimalist changes.


*
**Design Considerations:*

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.


The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum 
operating system required to run it.


The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the 
community before proposing this as a spec or blueprint.



*Approach 1*

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in 
glance were a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual 
machine.


Following are some of the changes to the OpenStack code that implements 
this approach:


1. Define a new conf parameter in nova called – 
/base_vm_image/=/var/lib/libvirt/images/baseimage.qcow2

This option is used to specify the base VM image.

2. define a new /sub_virt_type/ = container in nova conf. Setting this 
parameter will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type – this workflow will not work 
at this moment.


3. In the virt/libvirt/driver.py we do the following based on the 
sub_virt_type = container:


- We create a qcow2 disk from the /base_vm_image/ and expose that 'disk' 
as the boot disk for the virtual machine.
 Note – this is very similar to a regular virtual machine boot minus 
the fact that the image is not downloaded from

glance but instead it is present on the host.


- We download the docker image into the //var/lib/nova/instances/_base 
directory/ and then for each new virtual machine boot – we create a new 
directory //var/lib/nova/instances// as it's and copy the 
docker filesystem to it. Note – there are subsequent improvements to 
this idea that could be performed around the lines of using a union 
filesystem approach.


- The step above allows each virtual machine to have a different copy of 
the filesystem.


- We create a '/passthrough/' mount of the filesystem via libvirt. This 
code is also present in the nova libvirt driver and we just trigger it 
based on our sub_virt_type parameter.


4. A cloud init – userdata is provided that looks somewhat like this:
/
//runcmd://
//  - mount -t 9p -o trans=virtio share_dir /mnt//
//  - chroot /mnt /bin//

The /command_to_run /is usually the entrypoint to for the docker image.

There could be better approaches to determine the entrypoint as well 
(say from docker image metadata).


*
**Approach 2.*

In this approach, the workflow remains the same as the first one with 
the exception that the
docker image is changed into a qcow2 image using a tool like 
virt-make-fs before uploading it to glance, instead of a tar file.


A tool like virt-make-fs can convert a tar file to a qcow2 image very 
easily.


This image is then downloaded on the compute node and a qcow2 disk is 
created/attached to the virtual machine that boots using the 
/base_vm_image/.



*Approach 3*

A custom qcow2 image is created using kernel, initramfs and the docker 
image and uploaded to glance.  No changes are needed in openstack nova. 
It boots as a regular VM.


Changes will be needed in image generation tools and will involve few 
additional tasks from an operator point of view.



I look forward to your comments/suggestions on the above.


Thanks,

Sudipto

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-27 Thread Russell Bryant

On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton  wrote:

> > I'd like to see if we can solve the problems more generally.
>
> We've tried before but we very quickly run into competing requirements
> with regards to eventual consistency. For example, asynchronous background
> sync doesn't work if someone wants their backend to confirm that port
> details are acceptable (e.g. mac isn't in use by some other system outside
> of openstack). Then each backend has different methods for detecting what
> is out of sync (e.g. config numbers, hashes, or just full syncs on startup)
> that each come with their own requirements for how much data needs to be
> resent when an inconsistency is detected.
>
> If we can come to some common ground of what is required by all of them,
> then I would love to get some of this built into the ML2 framework.
> However, we've discussed this at meetups/mid-cycles/summits and it
> inevitably ends up with two people drawing furiously on a whiteboard,
> someone crying in the corner, and everyone else arguing about the lack of
> parametric polymorphism in Go.
>

Ha, yes, makes sense that this is really hard to solve in a way that works
for everyone ...



> Even between OVN and ODL in this thread, it sounds like the only thing in
> common is a background worker that consumes from a queue of tasks in the
> db. Maybe realistically the only common thing we can come up with is a
> taskflow queue stored in the DB to solve the multiple workers issue...
>

To clarify, ODL has this background worker and the discussion was whether
OVN should try to follow a similar approach.

So far, my gut feeling is that it's far too complicated for the problems it
would solve.  There's one identified multiple-worker related race condition
on updates, but I think we can solve that another way.



> On Tue, Jul 26, 2016 at 11:31 AM, Russell Bryant 
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique 
>> wrote:
>>
>>> Thanks for the comments Amitabha.
>>> Please see comments inline
>>>
>>> On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas 
>>> wrote:
>>>
 Hi Numan,

 Thanks for the proposal. We have also been thinking about this use-case.

 If I’m reading this accurately (and I may not be), it seems that the
 proposal is to not have any OVN NB (CUD) operations (R operations outside
 the scope) done by the api_worker threads but rather by a new journal
 thread.


>>> Correct.
>>> 
>>>
>>>
 If this is indeed the case, I’d like to consider the scenario when
 there any N neutron nodes, each node with M worker threads. The journal
 thread at the each node contain list of pending operations. Could there be
 (sequence) dependency in the pending operations amongst each the journal
 threads in the nodes that prevents them from getting applied (for e.g.
 Logical_Router_Port and Logical_Switch_Port inter-dependency), because we
 are returning success on neutron operations that have still not been
 committed to the NB DB.


>>> I
>>> ts a valid scenario and should be designed properly to handle such
>>> scenarios in case we take this approach.
>>>
>>
>> I believe a new table in the Neutron DB is used to synchronize all of
>> the journal threads.
>> 
>> Also note that OVN currently has no custom tables in the Neutron database
>> and it would be *very* good to keep it that way if we can.
>>
>>
>>>
>>> 
>>>
 Couple of clarifications and thoughts below.

 Thanks
 Amitabha 

 On Jul 13, 2016, at 1:20 AM, Numan Siddique 
 wrote:

 Adding the proper tags in subject

 On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique 
 wrote:

> Hi Neutrinos,
>
> Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and
> OVN DB
>  - At neutron-server startup, OVN ML2 driver syncs the neutron DB and
> OVN DB if sync mode is set to repair.
>  - Admin can run the "neutron-ovn-db-sync-util" to sync the DBs.
>
> Recently, in the v2 of networking-odl ML2 driver (Please see (1) below
> which has more details). (ODL folks please correct me if I am wrong here)
>
>   - a journal thread is created which does the CRUD operations of
> neutron resources asynchronously (i.e it sends the REST APIs to the ODL
> controller).
>

 Would this be the equivalent of making OVSDB transactions to the OVN NB
 DB?

>>>
>>> Correct.
>>> 
>>>
>>>

   - a maintenance thread is created which does some cleanup
> periodically and at startup does full sync if it detects ODL controller
> cold reboot.
>
>
> Few question I have
>  - can OVN ML2 driver take same or similar approach. Are there any
> advantages in taking this approach ? One advantage is neutron resources 
>

Re: [openstack-dev] [ptl][requirements] nomination period started