[openstack-dev] [Neutron][Dragonflow] - Documentation

[Gal Sagie]

Hello All,

We have recently uploaded a big amount of documents and diagrams to
Dragonflow
repository in order to expose what we are doing and make it as simple as we
can for new
contributors and users to start using Dragonflow.

I have created a wiki page for Dragonflow [1].

Some recommended documents:

- Dragonflow mission statement and high level architecture [2]
- Dragonflow pluggable DB architecture [3]
- Dragonflow Distributed DHCP implementation [4]
- Dragonflow OpenFlow Pipeline explained [5]

If you are both new or familiar with the project, i think you will find
these
interesting to read.

[1] https://wiki.openstack.org/wiki/Dragonflow
[2]
http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[3] http://docs.openstack.org/developer/dragonflow/pluggable_db.html
[4] http://docs.openstack.org/developer/dragonflow/distributed_dhcp.html
[5] http://docs.openstack.org/developer/dragonflow/pipeline.html
__
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] [all] tox 2.3.0 broke tempest jobs

[Jeremy Stanley]

On 2015-12-12 14:20:29 + (+), Yuriy Taraday wrote:
> Tempest jobs in all our projects seem to become broken after tox 2.3.0
> release yesterday. It's a regression in tox itself:
> https://bitbucket.org/hpk42/tox/issues/294
> 
> I suggest us to add tox to upper-constraints to avoid this breakage for now
> and in the future: https://review.openstack.org/256947

See my review comment, but this won't help.

> Note that we install tox in gate with no regard to global-requirements, so
> only upper-constraints can save us from tox releases.

No, it won't, since upper-constraints is merely used to constrain
requirements lists.
-- 
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] [all] tox 2.3.0 broke tempest jobs

[Jeremy Stanley]

On 2015-12-12 16:51:09 + (+), Jeremy Stanley wrote:
[...]
> No, it won't, since upper-constraints is merely used to constrain
> requirements lists.

I take that back, the pip_install function in DevStack applies
upper-constraints.txt on anything it installs, but regardless it's
misleading to try to pin it in upper-constraints.txt because that
won't help any of the numerous other jobs which may use constraints
but rely on preinstalled tox. Also I've confirmed that tempest jobs
do still seem to be working fine in our CI, and don't seem to be
unconditionally upgrading the preinstalled tox version. For the
benefit of people running DevStack themselves downstream, Ryan's
https://review.openstack.org/256620 looks like a more sensible
temporary workaround.
-- 
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] Mesos Conductor usingcontainer-createoperations

[Ton Ngo]

Hi Hongbin,
The proposal sounds reasonable:  basically it provides an agnostic
alternative to the single command line that a user can invoke with docker
or kubectl.  If the user needs more advanced support (environment
variables, volumes, network, ...), we would defer to the COE support and
the user would need to pick one.
I also notice that the command does not specify a bay.  If this is the
intention, this could also cover another use case that I hear frequently
when talking about Magnum:
"I just want to run some containers, I don't want to have to create a bay
or figure out what goes into a bay model"
In this case, there is probably a default bay model and a default bay
that would be created on the first invocation.  The command would take some
extra time the first time, but afterward it should be fast.  The default
configuration would come with Magnum, or be set by the cloud provider.
Ton,



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

Date:   12/10/2015 08:01 PM
Subject:Re: [openstack-dev] Mesos Conductor using   container-create
operations



Hi Ton,

Thanks for the feedback. Here is a clarification. The proposal is neither
for using existing DSL to express a container, nor for investing a new DSL.
Instead, I proposed to hide the complexity of existing DSLs and expose a
simple API to users. For example, if users want to create a container, they
could type something like:

magnum container-create –name XXX –image XXX –command XXX

Magnum will process the request and translate it to COE-specific API calls.
For k8s, we could dynamically generate a pod with a single container and
fill the pod with the inputted values (image, command, etc.). Similarly, in
marathon, we could generate an app based on inputs. A key advantage of that
is simple and doesn’t require COE-specific knowledge.

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: December-10-15 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Mesos Conductor using container-create
operations



I think extending the container object to Mesos via command like
container-create is a fine idea. Going into details, however, we run into
some complication.
1. The user would still have to choose a DSL to express the container. This
would have to be a kube and/or swarm DSL since we don't want to invent a
new one.
2. For Mesos bay in particular, kube or swarm may be running on top of
Mesos along side with Marathon, so somewhere along the line, Magnum has to
be able to make the distinction and handle things appropriately.

We should think through the scenarios carefully to come to agreement on how
this would work.

Ton Ngo,


Inactive hide details for Hongbin Lu ---12/09/2015 03:09:23 PM---As Bharath
mentioned, I am +1 to extend the "container" objectHongbin Lu ---12/09/2015
03:09:23 PM---As Bharath mentioned, I am +1 to extend the "container"
object to Mesos bay. In addition, I propose

From: Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: 12/09/2015 03:09 PM
Subject: Re: [openstack-dev] Mesos Conductor using container-create
operations




As Bharath mentioned, I am +1 to extend the “container” object to Mesos
bay. In addition, I propose to extend “container” to k8s as well (the
details are described in this BP [1]). The goal is to promote this API
resource to be technology-agnostic and make it portable across all COEs. I
am going to justify this proposal by a use case.

Use case:
I have an app. I used to deploy my app to a VM in OpenStack. Right now, I
want to deploy my app to a container. I have basic knowledge of container
but not familiar with specific container tech. I want a simple and
intuitive API to operate a container (i.e. CRUD), like how I operated a VM
before. I find it hard to learn the DSL introduced by a specific COE
(k8s/marathon). Most importantly, I want my deployment to be portable
regardless of the choice of cluster management system and/or container
runtime. I want OpenStack to be the only integration point, because I don’t
want to be locked-in to specific container tech. I want to avoid the risk
that a specific container tech being replaced by another in the future.
Optimally, I want Keystone to be the only authentication system that I need
to deal with. I don't want the extra complexity to deal with additional
authentication system introduced by specific COE.

Solution:
Implement "container" object for k8s and mesos bay (and all the COEs
introduced in the future).

That's it. I would appreciate if you can share your thoughts on this
proposal.

[1] https://blueprints.launchpad.net/magnum/+spec/unified-containers

Best regards,
Hongbin

From: bharath thiruveedula [mailto:bharath_...@hotmail.com]
Sent: December-08-15 11:40 

[openstack-dev] [all] tox 2.3.0 broke tempest jobs

[Yuriy Taraday]

Tempest jobs in all our projects seem to become broken after tox 2.3.0
release yesterday. It's a regression in tox itself:
https://bitbucket.org/hpk42/tox/issues/294

I suggest us to add tox to upper-constraints to avoid this breakage for now
and in the future: https://review.openstack.org/256947

Note that we install tox in gate with no regard to global-requirements, so
only upper-constraints can save us from tox releases.
__
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] [all] tox 2.3.0 broke tempest jobs

[Davanum Srinivas]

Good initiative, will have to get infra folks and lifeless to chime in. 

For now we need devstack cores help with merging possibly

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

-- dims


> On Dec 12, 2015, at 4:20 PM, Yuriy Taraday  wrote:
> 
> Tempest jobs in all our projects seem to become broken after tox 2.3.0 
> release yesterday. It's a regression in tox itself: 
> https://bitbucket.org/hpk42/tox/issues/294
> 
> I suggest us to add tox to upper-constraints to avoid this breakage for now 
> and in the future: https://review.openstack.org/256947
> 
> Note that we install tox in gate with no regard to global-requirements, so 
> only upper-constraints can save us from tox releases.
> __
> 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] [ansible] One or more undefined variables: 'dict object' has no attribute 'bridge'

[Wade Holler]

Hi Mark,

I haven't reviewed your configs yet but if "bridge" is a valid ansible
inventory attribute , then this error is usually caused by trying to
reference a host that ansible didn't check in on yet / gather facts on. At
least this is what is has been in my brief experience.

For example if I wanted to reference all hosts in a "webservers" ansible
group to build a haproxy config but that playbook didn't apply to the
"webservers" group them their facts have not been collected.

Just a thought.

Cheers
Wade


On Sat, Dec 12, 2015 at 9:34 AM Mark Korondi  wrote:

> Hi all,
>
> Trying to set up openstack-ansible, but stuck on this point:
>
> > TASK: [set local_ip fact (is_metal)]
> *
> > ...
> > fatal: [os-compute-1] => One or more undefined variables: 'dict object'
> has no
> > attribute 'bridge'
> > ...
> > One or more undefined variables: 'dict object' has no attribute 'bridge'
>
> These are my configs:
> - http://paste.openstack.org/show/481739/
>   (openstack_user_config.yml)
> - http://paste.openstack.org/show/481740/
>   (/etc/network/interfaces on compute host called `os-compute-1`)
>
> I set up the eth12 veth pair interface also on the compute host as you can
> see.
> `ifup-ifdown` works without any problems reported.
>
>
> Why is it reporting an undefined bridge variable? Any ideas on my config
> is well
> appreciated.
>
> Mark
>
> __
> 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] [all] tox 2.3.0 broke tempest jobs

[Davanum Srinivas]

Awesome thanks so much Jeremy for tracking this down.

-- Dims

On Sat, Dec 12, 2015 at 9:55 PM, Jeremy Stanley  wrote:
> On 2015-12-12 21:18:29 +0300 (+0300), Davanum Srinivas wrote:
>> Here's a really recent failure :
>> http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/devstacklog.txt.gz
>> tox still is 2.3.0 -
>> http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/pip-freeze.txt.gz
>
> According to
> http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/devstacklog.txt.gz#_2015-12-12_02_36_18_999
> it was not upgraded, implying that the version present on the system
> was already 2.3.0. It appears we had some additional "tainted"
> diskimages which were still in the process of being uploaded to
> hpcloud during my last pass of image deletes, so these have now been
> cleared out as well along with any ready nodes booted from them. Any
> rechecks past this point should run on nodes with an earlier
> (working) tox version.
>
> If anyone sees any further use of tox 2.3.0 after the time of this
> E-mail, please let us know.
> --
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [all] tox 2.3.0 broke tempest jobs

[Yuriy Taraday]

Hi, Jeremy.

On Sat, Dec 12, 2015 at 8:27 PM Jeremy Stanley  wrote:

> On 2015-12-12 16:51:09 + (+), Jeremy Stanley wrote:
> [...]
> > No, it won't, since upper-constraints is merely used to constrain
> > requirements lists.
>
> I take that back, the pip_install function in DevStack applies
> upper-constraints.txt on anything it installs, but regardless it's
> misleading to try to pin it in upper-constraints.txt because that
> won't help any of the numerous other jobs which may use constraints
> but rely on preinstalled tox.


I think it should be a good first step in right direction. For example,
with today's issue it would break gate for tempest itself only since all
other jobs would have preinstalled tox reverted to one mentioned in
upper-constraints.


> Also I've confirmed that tempest jobs
> do still seem to be working fine in our CI, and don't seem to be
> unconditionally upgrading the preinstalled tox version.


Pip doesn't upgrade tox if it is already installed, but will obey
constraints if they're provided. That's why it works with current reverted
image.

For the
> benefit of people running DevStack themselves downstream, Ryan's
> https://review.openstack.org/256620 looks like a more sensible
> temporary workaround.
>

Won't they use constraints too? I think we cover DevStack issue with
upper-constraints change as a more permanent solution.
__
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] [openstack][nova] Microversions support for extensions without Controller

[Alexandre Levine]

Hi all,

os-user-data extension implements server_create method to add user_data 
for server creation. No Controller is used for this, only "class 
UserData(extensions.V21APIExtensionBase)".


I want to add server_update method allowing to update the user_data. 
Obviously I have to add it as a microversioned functionality.


And here is the problem: there is no information about the incoming 
request version in this code. It is available for Controllers only. But 
checking the version in controller would be too late, because the 
instance is already updated (non-generator extensions are post-processed).


Can anybody guide me how to resolve this collision?

Would it be possible to just retroactively add the user_data 
modification for the whole 2.1 version skipping the microversioning? Or 
we need to change nova so that request version is passed through to 
extension?


Best regards,
  Alex Levine


__
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] Microversions support for extensions without Controller

[Alexandre Levine]

Hi all,

os-user-data extension implements server_create method to add user_data 
for server creation. No Controller is used for this, only "class 
UserData(extensions.V21APIExtensionBase)".


I want to add server_update method allowing to update the user_data. 
Obviously I have to add it as a microversioned functionality.


And here is the problem: there is no information about the incoming 
request version in this code. It is available for Controllers only. But 
checking the version in controller would be too late, because the 
instance is already updated (non-generator extensions are post-processed).


Can anybody guide me how to resolve this collision?

Would it be possible to just retroactively add the user_data 
modification for the whole 2.1 version skipping the microversioning? Or 
we need to change nova so that request version is passed through to 
extension?


Best regards,
  Alex Levine

P.S. Sorry for the second attempt - previous letter went with 
[openstack] instead of [openstack-dev] in the Subject.



__
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 metadata-agent HA

[Assaf Muller]

The neutron metadata agent is stateless. It takes requests from the
metadata proxies running in the router namespaces and moves the
requests on to the nova server. If you're using HA routers, start the
neutron-metadata-agent on every machine the L3 agent runs, and just
make sure that the metadata-agent is restarted in case it crashes and
you're done. Nothing else you need to do.

On Fri, Dec 11, 2015 at 3:24 PM, Fabrizio Soppelsa
 wrote:
>
> On Dec 10, 2015, at 12:56 AM, Alvise Dorigo 
> wrote:
>
> So my question is: is there any progress on this topic ? is there a way
> (something like a cronjob script) to make the metadata-agent redundant
> without involving the clustering software Pacemaker/Corosync ?
>
>
> Reason for such a dirty solution instead of rely onto pacemaker?
>
> I’m not aware of such initiatives - just checked the blueprints in Neutron
> and I found no relevant. I can suggest to file a proposal to the
> correspondent launchpad page, by elaborating your idea.
>
> F.
>
> __
> 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] [all] tox 2.3.0 broke tempest jobs

[Davanum Srinivas]

Jeremy,

Here's a really recent failure :
http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/devstacklog.txt.gz
tox still is 2.3.0 -
http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/pip-freeze.txt.gz

Thanks,
Dims

On Sat, Dec 12, 2015 at 8:26 PM, Jeremy Stanley  wrote:
> On 2015-12-12 16:51:09 + (+), Jeremy Stanley wrote:
> [...]
>> No, it won't, since upper-constraints is merely used to constrain
>> requirements lists.
>
> I take that back, the pip_install function in DevStack applies
> upper-constraints.txt on anything it installs, but regardless it's
> misleading to try to pin it in upper-constraints.txt because that
> won't help any of the numerous other jobs which may use constraints
> but rely on preinstalled tox. Also I've confirmed that tempest jobs
> do still seem to be working fine in our CI, and don't seem to be
> unconditionally upgrading the preinstalled tox version. For the
> benefit of people running DevStack themselves downstream, Ryan's
> https://review.openstack.org/256620 looks like a more sensible
> temporary workaround.
> --
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [all] tox 2.3.0 broke tempest jobs

[Yuriy Taraday]

On Sat, Dec 12, 2015 at 10:27 PM Jeremy Stanley  wrote:

> On 2015-12-12 19:00:23 + (+), Yuriy Taraday wrote:
> > I think it should be a good first step in right direction. For example,
> > with today's issue it would break gate for tempest itself only since all
> > other jobs would have preinstalled tox reverted to one mentioned in
> > upper-constraints.
> [...]
>
> Other way around. It would force DevStack to downgrade tox if the
> existing version on the worker were higher. Pretty much no other
> jobs install tox during the job, so they rely entirely on the one
> present on the system being correct and an entry for tox in
> upper-constraints.txt wouldn't help them at all, whether they're
> using that file to constrain their requirements lists or not (since
> tox is not present in any of our projects' requirements lists).
>

By "other" jobs I meant all jobs that use devstack to install tempest.
That's seem to be all jobs in all projects except probably tempest itself.

As for jobs that don't use devstack but only run tox, I suggest us to add a
step to adjust tox version according to upper-constraints as well.

Also, the constraints list is built from pip installing everything
> in global-requirements.txt into a virtualenv, so if tox is not a
> direct or transitive requirement then it will end up dropped from
> upper-constraints.txt on the next automated proposal in review.
>

Ok, will fix that in my CR.
__
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] [all] tox 2.3.0 broke tempest jobs

[Jeremy Stanley]

On 2015-12-12 21:18:29 +0300 (+0300), Davanum Srinivas wrote:
> Here's a really recent failure :
> http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/devstacklog.txt.gz
> tox still is 2.3.0 -
> http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/pip-freeze.txt.gz

According to
http://logs.openstack.org/30/256130/5/check/gate-tempest-dsvm-neutron-src-taskflow/5845dd4/logs/devstacklog.txt.gz#_2015-12-12_02_36_18_999
it was not upgraded, implying that the version present on the system
was already 2.3.0. It appears we had some additional "tainted"
diskimages which were still in the process of being uploaded to
hpcloud during my last pass of image deletes, so these have now been
cleared out as well along with any ready nodes booted from them. Any
rechecks past this point should run on nodes with an earlier
(working) tox version.

If anyone sees any further use of tox 2.3.0 after the time of this
E-mail, please let us know.
-- 
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] [all] tox 2.3.0 broke tempest jobs

[Jeremy Stanley]

On 2015-12-12 19:00:23 + (+), Yuriy Taraday wrote:
> I think it should be a good first step in right direction. For example,
> with today's issue it would break gate for tempest itself only since all
> other jobs would have preinstalled tox reverted to one mentioned in
> upper-constraints.
[...]

Other way around. It would force DevStack to downgrade tox if the
existing version on the worker were higher. Pretty much no other
jobs install tox during the job, so they rely entirely on the one
present on the system being correct and an entry for tox in
upper-constraints.txt wouldn't help them at all, whether they're
using that file to constrain their requirements lists or not (since
tox is not present in any of our projects' requirements lists).

Also, the constraints list is built from pip installing everything
in global-requirements.txt into a virtualenv, so if tox is not a
direct or transitive requirement then it will end up dropped from
upper-constraints.txt on the next automated proposal in review.
-- 
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] Mesos Conductor usingcontainer-createoperations

[Adrian Otto]

On Dec 12, 2015, at 9:19 AM, Ton Ngo > 
wrote:


Hi Hongbin,
The proposal sounds reasonable: basically it provides an agnostic alternative 
to the single command line that a user can invoke with docker or kubectl. If 
the user needs more advanced support (environment variables, volumes, network, 
...), we would defer to the COE support and the user would need to pick one.

I concur.

I also notice that the command does not specify a bay. If this is the 
intention, this could also cover another use case that I hear frequently when 
talking about Magnum:
"I just want to run some containers, I don't want to have to create a bay or 
figure out what goes into a bay model"
In this case, there is probably a default bay model and a default bay that 
would be created on the first invocation. The command would take some extra 
time the first time, but afterward it should be fast. The default configuration 
would come with Magnum, or be set by the cloud provider.

I like this idea.

Adrian

Ton,

Hongbin Lu ---12/10/2015 08:01:06 PM---Hi Ton, Thanks for the 
feedback. Here is a clarification. The proposal is neither for using existing

From: Hongbin Lu >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 12/10/2015 08:01 PM
Subject: Re: [openstack-dev] Mesos Conductor using container-create operations





Hi Ton,

Thanks for the feedback. Here is a clarification. The proposal is neither for 
using existing DSL to express a container, nor for investing a new DSL. 
Instead, I proposed to hide the complexity of existing DSLs and expose a simple 
API to users. For example, if users want to create a container, they could type 
something like:

magnum container-create –name XXX –image XXX –command XXX

Magnum will process the request and translate it to COE-specific API calls. For 
k8s, we could dynamically generate a pod with a single container and fill the 
pod with the inputted values (image, command, etc.). Similarly, in marathon, we 
could generate an app based on inputs. A key advantage of that is simple and 
doesn’t require COE-specific knowledge.

Best regards,
Hongbin

From: Ton Ngo [mailto:t...@us.ibm.com]
Sent: December-10-15 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Mesos Conductor using container-create operations

I think extending the container object to Mesos via command like 
container-create is a fine idea. Going into details, however, we run into some 
complication.
1. The user would still have to choose a DSL to express the container. This 
would have to be a kube and/or swarm DSL since we don't want to invent a new 
one.
2. For Mesos bay in particular, kube or swarm may be running on top of Mesos 
along side with Marathon, so somewhere along the line, Magnum has to be able to 
make the distinction and handle things appropriately.

We should think through the scenarios carefully to come to agreement on how 
this would work.

Ton Ngo,


Hongbin Lu ---12/09/2015 03:09:23 PM---As Bharath mentioned, I am 
+1 to extend the "container" object to Mesos bay. In addition, I propose

From: Hongbin Lu >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 12/09/2015 03:09 PM
Subject: Re: [openstack-dev] Mesos Conductor using container-create operations






As Bharath mentioned, I am +1 to extend the “container” object to Mesos bay. In 
addition, I propose to extend “container” to k8s as well (the details are 
described in this BP [1]). The goal is to promote this API resource to be 
technology-agnostic and make it portable across all COEs. I am going to justify 
this proposal by a use case.

Use case:
I have an app. I used to deploy my app to a VM in OpenStack. Right now, I want 
to deploy my app to a container. I have basic knowledge of container but not 
familiar with specific container tech. I want a simple and intuitive API to 
operate a container (i.e. CRUD), like how I operated a VM before. I find it 
hard to learn the DSL introduced by a specific COE (k8s/marathon). Most 
importantly, I want my deployment to be portable regardless of the choice of 
cluster management system and/or container runtime. I want OpenStack to be the 
only integration point, because I don’t want to be locked-in to specific 
container tech. I want to avoid the risk that a specific container tech being 
replaced by another in the future. Optimally, I want Keystone to be the only 
authentication system that I need to deal with. I don't want the extra 
complexity to deal with additional authentication system introduced by specific 
COE.

Solution:
Implement "container" 

Re: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for "Cannot set up guest memory 'pc.ram': Cannot allocate memory"

[Hongbin Lu]

Hi,

As Kai Qiang mentioned, magnum gate recently had a bunch of random failures, 
which occurred on creating a nova instance with 2G of RAM. According to the 
error message, it seems that the hypervisor tried to allocate memory to the 
nova instance but couldn’t find enough free memory in the host. However, by 
adding a few “nova hypervisor-show XX” before, during, and right after the 
test, it showed that the host has 6G of free RAM, which is far more than 2G. 
Here is a snapshot of the output [1]. You can find the full log here [2].

Another observation is that most of the failure happened on a node with name 
“devstack-trusty-ovh-*” (You can verify it by entering a query [3] at 
http://logstash.openstack.org/ ). It seems that the jobs will be fine if they 
are allocated to a node other than “ovh”.

Any hints to debug this issue further? Suggestions are greatly appreciated.

[1] http://paste.openstack.org/show/481746/
[2] 
http://logs.openstack.org/48/256748/1/check/gate-functional-dsvm-magnum-swarm/56d79c3/console.html
[3] https://review.openstack.org/#/c/254370/2/queries/1521237.yaml

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: December-09-15 7:23 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Infra][nova][magnum] Jenkins failed quite often for 
"Cannot set up guest memory 'pc.ram': Cannot allocate memory"


Hi All,

I am not sure what changes these days, We found quite often now, the Jenkins 
failed for:


http://logs.openstack.org/07/244907/5/check/gate-functional-dsvm-magnum-k8s/5305d7a/logs/libvirt/libvirtd.txt.gz

2015-12-09 
08:52:27.892+:
 22957: debug : qemuMonitorJSONCommandWithFd:264 : Send command 
'{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1
2015-12-09 
08:52:27.892+:
 22957: debug : qemuMonitorSend:959 : QEMU_MONITOR_SEND_MSG: mon=0x7fa66400c6f0 
msg={"execute":"qmp_capabilities","id":"libvirt-1"}
 fd=-1
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, 
called from event watch 6
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:360 : event not handled.
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, 
called from event watch 6
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:360 : event not handled.
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:347 : dispatching to max 0 clients, 
called from event watch 6
2015-12-09 
08:52:27.941+:
 22951: debug : virNetlinkEventCallback:360 : event not handled.
2015-12-09 
08:52:28.070+:
 22951: error : qemuMonitorIORead:554 : Unable to read from monitor: Connection 
reset by peer
2015-12-09 
08:52:28.070+:
 22951: error : qemuMonitorIO:690 : internal error: early end of file from 
monitor: possible problem:
Cannot set up guest memory 'pc.ram': Cannot allocate memory




It not hit such resource issue before. I am not sure if Infra or nova guys know 
about it ?


Thanks

Best Wishes,

Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle!