Re: [openstack-dev] [all] re-introducing twisted to global-requirements

[Jay Pipes]

On 01/07/2016 06:12 PM, Ben Meyer wrote:

On 01/07/2016 03:32 PM, Jay Pipes wrote:

On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:

On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:

On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:

Hi all,

A change to global-requirements[1] introduces mimic, which is an http
server that can mock various APIs, including nova and ironic,
including
control of error codes and timeouts. The ironic team plans to use this
for testing python-ironicclient without standing up a full ironic
environment.

Here's the catch - mimic is built on twisted. I know twisted was
previously removed from OpenStack (or at least people said "pls no", I
don't know the full history). We didn't intend to stealth-introduce
twisted back into g-r, but it was pointed out to me that it may appear
this way, so here I am letting everyone know. lifeless pointed out
that
when tests are failing, people may end up digging into mimic or
twisted
code, which most people in this community aren't familiar with AFAIK,
which is a valid point though I hope it isn't required often.

So, the primary question here is: do folks have a problem with adding
twisted here? We're holding off on Ironic changes that depend on this
until this discussion has happened, but aren't reverting the g-r
change
until we decide one way or another.

// jim

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


What is the advantage of running another server like this over using
requests-mock (which is used by other OpenStack projects for testing
today)? The only difference here seems to be that you actually execute
requests code in one case and not in the other.

Requests-mock debugging when things go wrong seems a bit simpler.

This is less about twisted and more about trying to not introduce yet
another way to mock code in the tree that people need to understand.

 -Sean


We'd be using this for functional tests, not unit, where we can't really
inject mocks. The idea is that we could run a full functional suite
against either mimic or a full ironic environment, just by changing a
test setting.


I don't really see the point of a separate project like Mimic that has
a whole bunch of reimplementations (mocked out) of all sorts of
OpenStack (and RAX-specific) API services. It's just a great way to
introduce a larger surface area for bugs to creep in -- since you have
to keep the Mimic interfaces up to date with the real interfaces.
Better to keep something like this -- if it is TRULY needed -- in-tree
with the API service itself, so that the chances of divergence are
reduced. This is similar to the fakevirt driver in Nova. It's in tree
for good reason: when someone changes the virt driver interface, the
fakevirt driver goes boom and needs to be changed in a corresponding
fashion in the same patch.

A tool like my OpenStackInABox could certainly benefit from the models
or services being provided by each project - aside from the complexity
that that adds to the installation of installing all the dependencies
related instead of just implementing a simple model with a file and
sqlite backend that has minimal dependencies...but I digress as I
haven't looked at how nova's fakevirt driver installs so may be that's
not as big an issue. I'll certainly look at it for use in
OpenStackInABox, but even there I'm aiming for a more complete scenario
where you can interact with Keystone, Nova, Swift, etc...(e.g auth
against a fake Keystone, use the token with the fake nova which
validates it against the same fake Keystone instance, same with a fake
Swift...).


But your fake Keystone wouldn't be "authing" anything at all. Your fake 
Nova wouldn't be "validating" anything at all.


You aren't *functionally* testing anything of importance above if the 
things you are testing aren't doing what they are supposed to do.


The only things you are functionally testing are the *clients* to those 
fake HTTP services. And what you are *actually* validating the client 
code for isn't *actually* the real HTTP API service -- it's a fake which 
can have its own surface area for bugginess -- which takes me back to my 
original question: what value does one get from *functional* tests of a 
client that calls a faked-out HTTP API versus *unit* tests of said 
client that simply uses requests-mock (or similar) to set the returned 
value of the HTTP API service to some expected value?



What value does a functional test against an HTTP API service that
does nothing (other than introduce greater surface area for bugs)
actually offer over unit tests anyway?


So to use Nova's fakevirt your project is limited to the same language
as nova - python, correct?


Nova's fakevirt driver simply does NOOP calls for most things and some 
light in-memory bookkeeping of resources that a normal virt driver 
would, in reality, consume from the host. It's a way we have to "test" 
launching many instances in Nova without actually having those instances 
consume resource on the host.

Re: [openstack-dev] [magnum] Temporarily remove swarm func test from gate

[Hongbin Lu]

Clark,

That is true. The check pipeline must pass in order to enter the gate pipeline. 
Here is the problem we are facing. A patch that was able to pass the check 
pipeline is blocked in gate pipeline, due to the instability of the test. The 
removal of unstable test from gate pipeline aims to unblock the patches that 
already passed the check.

An alternative is to remove the unstable test from check pipeline as well or 
mark it as non-voting test. If that is what the team prefers, I will adjust the 
review accordingly.

Best regards,
Honbgin

-Original Message-
From: Clark Boylan [mailto:cboy...@sapwetik.org] 
Sent: January-07-16 6:04 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from 
gate

On Thu, Jan 7, 2016, at 02:59 PM, Hongbin Lu wrote:
> Hi folks,
> 
> It looks the swarm func test is currently unstable, which negatively 
> impacts the patch submission workflow. I proposed to remove it from 
> Jenkins gate (but keep it in Jenkins check), until it becomes stable.
> Please find the details in the review
> (https://review.openstack.org/#/c/264998/) and let me know if you have 
> any concern.
> 
Removing it from gate but not from check doesn't necessarily help much because 
you can only enter the gate pipeline once the change has a +1 from Jenkins. 
Jenkins applies the +1 after check tests pass.

Clark

__
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] [infra][stackalytics] some projects not visible in stackalytics now

[joehuang]

Only api-wg, openstack-user-stories, opos-tools-contrib, opos-tools-generic, 
opos-tools-monitoring are listed in 
http://stackalytics.com/?project_type=openstack-others

Many OpenStack other projects are disappeared.

Best Regards
Chaoyi Huang ( Joe Huang )

From: HADDLETON, Robert W (Bob) [mailto:bob.haddle...@alcatel-lucent.com]
Sent: Thursday, January 07, 2016 10:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][stackalytics] some projects not visible in 
stackalytics now

The Tacker[1] project is also missing from the list of Openstack-other projects 
on stackalytics.

[1] https://github.com/openstack/tacker/

Bob

On 1/7/2016 3:02 AM, joehuang wrote:
Hello,

Both Kingbird[1] and Tricircle[2] are not visible in stackalytics.com now, 
which are projects under OpenStack name space.  Some days ago these two 
projects are listed in http://stackalytics.com/?project_type=openstack-others

Maybe I missed some mail, don’t know what happened, or something wrong in 
configuration in Infra or stackalytics?

[1] https://github.com/openstack/kingbird/
[2] https://github.com/openstack/tricircle

Best Regards
Chaoyi Huang ( Joe Huang )




__

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] RDO, packstack, Keypair creation is failing

[Thales]

Hello,
I'm trying to learn OpenStack via RDO, so I downloaded packstack.  I went to 
this link to start on RDOhttps://www.rdoproject.org/install/quickstart/

I set up a fixed IP in CentOS 7.    CentOS 7 is a guest OS.   I'm using 
Virtualbox as my virtual machine, and Windows 10 is my host OS.  I'm using a 
Bridged adpater for Virtual Box.
I downloaded and installed RDO via packstack.
I then went here:https://www.rdoproject.org/install/running-an-instance/


I went there to learn how to run an instance, and on step three on that page, 
"Create or Import a Pair", I  received an error.    The error occurred when I 
tried to "create" the key.  It error was "Keypair data is invalid: failed to 
generate fingerprint (HTTP 400)".     I also tried to import a key, by 
generating one on the command line.  However, in both cases it failed.  I got 
some guidance from this video,https://www.youtube.com/watch?v=GYTctLuPbOs, but 
that didn't do the trick for me, either.

  I have been looking around for similar problems on the web, and I found a 
couple, but none of the solutions worked for me.
  Does anyone have any idea what his could be?   I'm really just learning now, 
so I'm sure it's got to be something rudimentary.
  Thanks for any help!
  ...John


  __
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] [trove] Adding support for HBase in Trove

[Fox, Kevin M]

While I applaud raising the issue on the mailing list to get more folks to 
weigh in, I think part of the problem maybe the lack of a [sahara] tag on the 
subject. The thread is still tagged to be a Trove centric conversation. All 
respondents please consider adding [sahara] to the subject.

Thanks,
Kevin

From: Amrith Kumar [amr...@tesora.com]
Sent: Thursday, January 07, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove

> -Original Message-
> From: michael mccune [mailto:m...@redhat.com]
> Sent: Thursday, January 07, 2016 3:12 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
>
> On 01/07/2016 11:59 AM, Amrith Kumar wrote:
> >  From the things that you and Pete (Peter MacKinnon) are saying, I don't
> understand why there is an objection to accepting the currently proposed
> implementation which is clearly for single node deployments? Both
> Standalone and Pseudo-Distributed are by definition, explicitly, necessarily,
> absolutely, positively, definitely single node. I can't be more explicit about
> that. That's all that is being proposed at this time. See more comments
> below.
>
> i didn't think i explicitly objected to the spec, if it seems that way then i
> apologize. after reading the spec and the comments, it seemed that there
> was some question about engagement with the sahara team. i wanted to
> help bring some light to the issues surrounding deploying hbase and thought
> it would be good to participate in the discussion.

You are correct Michael. There was a suggestion that we should engage with the 
Sahara team (in the Trove team meeting yesterday) and that is what prompted 
this email thread. So I appreciate your participation as one who is a member of 
the Sahara team.

>
> > Further, the current proposal also chooses an implementation strategy that
> makes it much easier to handle fully-distributed in a different way in the
> future. Consider this, Trove could equally well have dealt with HBase using a
> single datastore for all operating modes. In the current implementation, one
> would create a HBase standalone instance using a command that included:
> >
> > --datastore hbase-standalone
> >
> > And a pseudo-distributed instance by including
> >
> > --datastore hbase-pseudo-distributed.
> >
>
> and this delineation sounds reasonable to me
>
> > Trove could equally well function by having a single datastore (hbase) but
> this would make hbase-fully-distributed harder to do in a different way in the
> future. I consciously eschewed that path, for this very specific reason; it
> would limit choice in the future.
>
> agreed
>
> > Now, the implementation behind hbase-fully-distributed could be a
> custom Trove guest agent that could (if we decided to go that route) interact
> with Sahara. However, an alternative implementation of hbase-fully-
> distributed could orchestrate everything natively in Trove. There is much
> flexibility in the current proposal, and I submit to you that this is being 
> lost in
> your reading of the specification and the current implementation as
> proposed.
>
> i don't think your characterization of my reading comprehension is fair.
> as i stated earlier, i wanted to participate in the discussion surrounding
> deploying a technology that sahara currently deploys. fwiw, i agree with what
> you are saying here, but i also think it is axiomatic, the trove team can 
> choose
> whichever path it would like for implementation.
>
> >> i think this sounds reasonable, as long as we are limiting it to
> >> standalone mode. if the deployments start to take on a larger scope i
> >> agree it would be useful to leverage sahara for provisioning and scaling.
> >
> > Why only standalone? The current proposal explicitly covers only
> standalone and pseudo-distributed which are both valid strictly (add other
> adjectives here to taste) single node topologies and the currently submitted
> specification specifically carves out fully-distributed operation as requiring
> further thought and contemplation.
>
> i think starting with standalone mode (and not pseudo-distributed) is a more
> conservative approach to this. my reason for suggesting limiting this to
> standalone is that even in pseudo-distributed mode the need for managing
> hdfs and zookeeper are present, i wanted to highlight some of of the overlap
> and the issues that will start to creep in surrounding this deployment.
>

The current code (submitted for review) provides both standalone and 
pseudo-distributed support. You will observe that the standalone and 
pseudo-distributed implementations do install zookeeper. As you are no doubt 
aware, one of the recommended ways to force the HBase Master server to always 
bind to a well-known port in favor of the ephemeral ports is to stipulate  

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

[James Bottomley]

On Thu, 2016-01-07 at 16:55 -0800, Yuhong Bao wrote:
> > > I read the patent and it looks like UEFI or for that matter any
> > > non
> > > -Windows implementation of FAT would probably not infringe on the
> > > patent.
> > 
> > Well, I'm not going to give you a legal opinion. However, most
> > people
> > think this patent covers the long vs short filenames conversions
> > used
> > by vfat. The UEFI implementation definitely implements the long vs
> > short name conversions for FAT/VFAT compatibility.
> > 
> > James
> 
> I actually read the claims in the patent and my point is that it
> mostly only covers the INT 21h interface in Win9x,
> which UEFI or for that matter Linux don't use.

Um, that's the first two independent claims.  The long filename stuff
begins at claim 4.

James



__
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] [stable] kilo and liberty is blocked on bug 1532048

[Matt Riedemann]

django_compressor 2.0 was released today which drops support for 
django<1.8 which is what stable/kilo g-r has django capped at, so 
horizon fails to install in kilo which breaks kilo jobs and grenade jobs 
in liberty.


The cap in stable/kilo g-r is here:

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

I'll babysit the reqs sync to horizon in kilo tonight which should then 
free things up again.


--

Thanks,

Matt Riedemann


__
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] re-introducing twisted to global-requirements

[David Stanek]

On Thu, Jan 7, 2016 at 3:01 PM, Jim Rollenhagen 
wrote:

> We'd be using this for functional tests, not unit, where we can't really
> inject mocks. The idea is that we could run a full functional suite
> against either mimic or a full ironic environment, just by changing a
> test setting.
>

I'm assuming that this would be for client functional tests because it
wouldn't make sense for testing a server. How is the interface created? It
seems like it would be possible for the mocked API to not match the actual
API.


-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
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] Temporarily remove swarm func test from gate

[Clark Boylan]

On Thu, Jan 7, 2016, at 02:59 PM, Hongbin Lu wrote:
> Hi folks,
> 
> It looks the swarm func test is currently unstable, which negatively
> impacts the patch submission workflow. I proposed to remove it from
> Jenkins gate (but keep it in Jenkins check), until it becomes stable.
> Please find the details in the review
> (https://review.openstack.org/#/c/264998/) and let me know if you have
> any concern.
> 
Removing it from gate but not from check doesn't necessarily help much
because you can only enter the gate pipeline once the change has a +1
from Jenkins. Jenkins applies the +1 after check tests pass.

Clark

__
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] re-introducing twisted to global-requirements

[Ben Meyer]

On 01/07/2016 03:32 PM, Jay Pipes wrote:
> On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:
>> On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:
>>> On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:
 Hi all,

 A change to global-requirements[1] introduces mimic, which is an http
 server that can mock various APIs, including nova and ironic,
 including
 control of error codes and timeouts. The ironic team plans to use this
 for testing python-ironicclient without standing up a full ironic
 environment.

 Here's the catch - mimic is built on twisted. I know twisted was
 previously removed from OpenStack (or at least people said "pls no", I
 don't know the full history). We didn't intend to stealth-introduce
 twisted back into g-r, but it was pointed out to me that it may appear
 this way, so here I am letting everyone know. lifeless pointed out
 that
 when tests are failing, people may end up digging into mimic or
 twisted
 code, which most people in this community aren't familiar with AFAIK,
 which is a valid point though I hope it isn't required often.

 So, the primary question here is: do folks have a problem with adding
 twisted here? We're holding off on Ironic changes that depend on this
 until this discussion has happened, but aren't reverting the g-r
 change
 until we decide one way or another.

 // jim

 [1] https://review.openstack.org/#/c/220268/
>>>
>>> What is the advantage of running another server like this over using
>>> requests-mock (which is used by other OpenStack projects for testing
>>> today)? The only difference here seems to be that you actually execute
>>> requests code in one case and not in the other.
>>>
>>> Requests-mock debugging when things go wrong seems a bit simpler.
>>>
>>> This is less about twisted and more about trying to not introduce yet
>>> another way to mock code in the tree that people need to understand.
>>>
>>> -Sean
>>
>> We'd be using this for functional tests, not unit, where we can't really
>> inject mocks. The idea is that we could run a full functional suite
>> against either mimic or a full ironic environment, just by changing a
>> test setting.
>
> I don't really see the point of a separate project like Mimic that has
> a whole bunch of reimplementations (mocked out) of all sorts of
> OpenStack (and RAX-specific) API services. It's just a great way to
> introduce a larger surface area for bugs to creep in -- since you have
> to keep the Mimic interfaces up to date with the real interfaces.
> Better to keep something like this -- if it is TRULY needed -- in-tree
> with the API service itself, so that the chances of divergence are
> reduced. This is similar to the fakevirt driver in Nova. It's in tree
> for good reason: when someone changes the virt driver interface, the
> fakevirt driver goes boom and needs to be changed in a corresponding
> fashion in the same patch.
A tool like my OpenStackInABox could certainly benefit from the models
or services being provided by each project - aside from the complexity
that that adds to the installation of installing all the dependencies
related instead of just implementing a simple model with a file and
sqlite backend that has minimal dependencies...but I digress as I
haven't looked at how nova's fakevirt driver installs so may be that's
not as big an issue. I'll certainly look at it for use in
OpenStackInABox, but even there I'm aiming for a more complete scenario
where you can interact with Keystone, Nova, Swift, etc...(e.g auth
against a fake Keystone, use the token with the fake nova which
validates it against the same fake Keystone instance, same with a fake
Swift...).

> What value does a functional test against an HTTP API service that
> does nothing (other than introduce greater surface area for bugs)
> actually offer over unit tests anyway?

So to use Nova's fakevirt your project is limited to the same language
as nova - python, correct?

The main advantage of mimic is that it is language agnostic and multiple
moving parts (f.e taskflow) can interact with it.

$0.02

Ben


__
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] [Magnum] Networking Subteam Update

[Daneyon Hansen (danehans)]

All,

Today the Magnum networking subteam decided to merge back into the general 
Magnum community. I would like to thank all who participated in the subteam 
over the past 6 months. We were able to develop and implement the Magnum 
Container Networking Model [1]. I look forward to additional network drivers 
being added in the future to expand Magnum's container networking capabilities. 
Details of Magnum's networking can be found in the Resources Section [2] of the 
Magnum wiki. Please use the #openstack-containers IRC channel and the mailing 
list for Magnum-related questions or discussion. Feel free to also join the 
weekly Magnum IRC meeting [3].

[1] 
https://github.com/openstack/magnum/blob/master/specs/container-networking-model.rst
[2] https://wiki.openstack.org/wiki/Magnum#Resources
[3] 
https://wiki.openstack.org/wiki/Meetings/Containers#Weekly_Containers_Team_Meeting

Regards,
Daneyon Hansen

__
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] re-introducing twisted to global-requirements

[Jim Rollenhagen]

On Thu, Jan 07, 2016 at 07:18:15PM -0500, Jay Pipes wrote:
> On 01/07/2016 06:42 PM, Jim Rollenhagen wrote:
> >On Thu, Jan 07, 2016 at 03:32:39PM -0500, Jay Pipes wrote:
> >>On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:
> >>>On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:
> On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:
> >Hi all,
> >
> >A change to global-requirements[1] introduces mimic, which is an http
> >server that can mock various APIs, including nova and ironic, including
> >control of error codes and timeouts. The ironic team plans to use this
> >for testing python-ironicclient without standing up a full ironic
> >environment.
> >
> >Here's the catch - mimic is built on twisted. I know twisted was
> >previously removed from OpenStack (or at least people said "pls no", I
> >don't know the full history). We didn't intend to stealth-introduce
> >twisted back into g-r, but it was pointed out to me that it may appear
> >this way, so here I am letting everyone know. lifeless pointed out that
> >when tests are failing, people may end up digging into mimic or twisted
> >code, which most people in this community aren't familiar with AFAIK,
> >which is a valid point though I hope it isn't required often.
> >
> >So, the primary question here is: do folks have a problem with adding
> >twisted here? We're holding off on Ironic changes that depend on this
> >until this discussion has happened, but aren't reverting the g-r change
> >until we decide one way or another.
> >
> >// jim
> >
> >[1] https://review.openstack.org/#/c/220268/
> 
> What is the advantage of running another server like this over using
> requests-mock (which is used by other OpenStack projects for testing
> today)? The only difference here seems to be that you actually execute
> requests code in one case and not in the other.
> 
> Requests-mock debugging when things go wrong seems a bit simpler.
> 
> This is less about twisted and more about trying to not introduce yet
> another way to mock code in the tree that people need to understand.
> 
>   -Sean
> >>>
> >>>We'd be using this for functional tests, not unit, where we can't really
> >>>inject mocks. The idea is that we could run a full functional suite
> >>>against either mimic or a full ironic environment, just by changing a
> >>>test setting.
> >>
> >>I don't really see the point of a separate project like Mimic that has a
> >>whole bunch of reimplementations (mocked out) of all sorts of OpenStack (and
> >>RAX-specific) API services. It's just a great way to introduce a larger
> >>surface area for bugs to creep in -- since you have to keep the Mimic
> >>interfaces up to date with the real interfaces. Better to keep something
> >>like this -- if it is TRULY needed -- in-tree with the API service itself,
> >>so that the chances of divergence are reduced. This is similar to the
> >>fakevirt driver in Nova. It's in tree for good reason: when someone changes
> >>the virt driver interface, the fakevirt driver goes boom and needs to be
> >>changed in a corresponding fashion in the same patch.
> >
> >I tend to think our REST APIs are much more stable than internal python
> >APIs, and so we can manage the divergence much easier.
> >
> >Also, mimic can simulate:
> >
> >* old versions (less needed with all the microversion stuff)
> >* old bugs that were shipped
> >* misconfigurations
> >* networking errors
> >* the passage of time (including timeouts)
> >
> >We probably don't want to keep a catalog of old bugs and misconfigurations in
> >tree forever.
> >
> >>What value does a functional test against an HTTP API service that does
> >>nothing (other than introduce greater surface area for bugs) actually offer
> >>over unit tests anyway?
> >
> >Testing the full stack of the client instead of mocking the bottom
> >half of requests is a big one.
> >
> >Lekha and Glyph gave a talk on Mimic in Paris; it may be enlightening.
> >https://www.youtube.com/watch?v=HKUUQme3dwA
> 
> OK, I just watched that. Sorry, still don't see the value that Mimic
> provides over unit testing the client interfaces and mocking out the HTTP
> payloads so you have strict control over the expectations.
> 
> The problem that Glyph noted in the video about the unit test that mocked
> out os.chdir to improperly return a value isn't solved whatsoever by Mimic,
> so I find it odd that that example was used in discussing the value of
> Mimic. Bad mocks are just that: bad mocks. The same false positive failure
> could easily be introduced with a typo in the "metadata injection" that
> Mimic does to inject failures into the system.
> 
> Mimic isn't testing anything on the server side at all so I'm not sure why
> folks call it "integration testing". It isn't testing the integration of
> anything at all. All it enables is multi-language client library testing,
> and see my 

[openstack-dev] [magnum] Temporarily remove swarm func test from gate

[Hongbin Lu]

Hi folks,

It looks the swarm func test is currently unstable, which negatively impacts 
the patch submission workflow. I proposed to remove it from Jenkins gate (but 
keep it in Jenkins check), until it becomes stable. Please find the details in 
the review (https://review.openstack.org/#/c/264998/) and let me know if you 
have any concern.

Best regards,
Hongbin
__
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] [doc] DocImpact vs. reno

[Lana Brindley]

> On 7 Jan 2016, at 2:09 AM, Sean Dague  wrote:
> 
> On 01/06/2016 09:02 AM, Jeremy Stanley wrote:
>> On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
>> [...]
>>> I think auto openning against a project, and shuffling it to
>>> manuals manually (with details added by humans) would be fine.
>>> 
>>> It's not clear to me why a new job was required for that.
>> 
>> The new check job was simply a requirement of the Docs team, since
>> they were having trouble triaging auto-generated bugs they were
>> receiving and wanted to enforce the inclusion of some expository
>> metadata.
> 
> Sure, but if that triage is put back on the Nova team, that seems fine.

So you’re thinking we should make all docimpact bugs go to the project bug 
queue? Even for defcore?


> 
> It also doesn't make sense to me there would be a DocImpact change that
> wouldn't also have a reno section. The reason someone thinks that a
> change needs reflection in the manual is that it adds/removes/changes a
> feature that would also show up in release notes. Perhaps my imagination
> isn't sufficient to come up with a scenario where DocImpact is valid,
> but we wouldn't have content in one of those sections.

I can think of plenty. What about where a command is changed slightly? Or an 
output is formatted differently? Or where flags have been removed, or default 
values changed, or ….

Bugs and relnotes are two very different things.

L

Lana Brindley
writer:speaker:blogger
http://lanabrindley.com





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] [all] re-introducing twisted to global-requirements

[Jim Rollenhagen]

On Thu, Jan 07, 2016 at 03:32:39PM -0500, Jay Pipes wrote:
> On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:
> >On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:
> >>On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:
> >>>Hi all,
> >>>
> >>>A change to global-requirements[1] introduces mimic, which is an http
> >>>server that can mock various APIs, including nova and ironic, including
> >>>control of error codes and timeouts. The ironic team plans to use this
> >>>for testing python-ironicclient without standing up a full ironic
> >>>environment.
> >>>
> >>>Here's the catch - mimic is built on twisted. I know twisted was
> >>>previously removed from OpenStack (or at least people said "pls no", I
> >>>don't know the full history). We didn't intend to stealth-introduce
> >>>twisted back into g-r, but it was pointed out to me that it may appear
> >>>this way, so here I am letting everyone know. lifeless pointed out that
> >>>when tests are failing, people may end up digging into mimic or twisted
> >>>code, which most people in this community aren't familiar with AFAIK,
> >>>which is a valid point though I hope it isn't required often.
> >>>
> >>>So, the primary question here is: do folks have a problem with adding
> >>>twisted here? We're holding off on Ironic changes that depend on this
> >>>until this discussion has happened, but aren't reverting the g-r change
> >>>until we decide one way or another.
> >>>
> >>>// jim
> >>>
> >>>[1] https://review.openstack.org/#/c/220268/
> >>
> >>What is the advantage of running another server like this over using
> >>requests-mock (which is used by other OpenStack projects for testing
> >>today)? The only difference here seems to be that you actually execute
> >>requests code in one case and not in the other.
> >>
> >>Requests-mock debugging when things go wrong seems a bit simpler.
> >>
> >>This is less about twisted and more about trying to not introduce yet
> >>another way to mock code in the tree that people need to understand.
> >>
> >>-Sean
> >
> >We'd be using this for functional tests, not unit, where we can't really
> >inject mocks. The idea is that we could run a full functional suite
> >against either mimic or a full ironic environment, just by changing a
> >test setting.
> 
> I don't really see the point of a separate project like Mimic that has a
> whole bunch of reimplementations (mocked out) of all sorts of OpenStack (and
> RAX-specific) API services. It's just a great way to introduce a larger
> surface area for bugs to creep in -- since you have to keep the Mimic
> interfaces up to date with the real interfaces. Better to keep something
> like this -- if it is TRULY needed -- in-tree with the API service itself,
> so that the chances of divergence are reduced. This is similar to the
> fakevirt driver in Nova. It's in tree for good reason: when someone changes
> the virt driver interface, the fakevirt driver goes boom and needs to be
> changed in a corresponding fashion in the same patch.

I tend to think our REST APIs are much more stable than internal python
APIs, and so we can manage the divergence much easier.

Also, mimic can simulate:

* old versions (less needed with all the microversion stuff)
* old bugs that were shipped
* misconfigurations
* networking errors
* the passage of time (including timeouts)

We probably don't want to keep a catalog of old bugs and misconfigurations in
tree forever.

> What value does a functional test against an HTTP API service that does
> nothing (other than introduce greater surface area for bugs) actually offer
> over unit tests anyway?

Testing the full stack of the client instead of mocking the bottom
half of requests is a big one.

Lekha and Glyph gave a talk on Mimic in Paris; it may be enlightening.
https://www.youtube.com/watch?v=HKUUQme3dwA

// 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

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Fox, Kevin M]

thats somewhat limiting though...

We use ceph here because we can pool our storage between the swift protocol 
endpoint, and the block storage system. It doesn't make us partition up our 
storage. I can totally see a case where you'd maybe just scale out your 
undercloud ceph for use in the overcloud, rather then stand up a whole other 
storage system and have to partition your storage.

Thanks,
Kevin

From: Dan Prince [dpri...@redhat.com]
Sent: Thursday, January 07, 2016 11:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] Is Swift a good choice of database for 
the TripleO API?

On Thu, 2016-01-07 at 18:16 +, Fox, Kevin M wrote:
> I don't think the radosgw supports bulk yet. They haven't for a very
> long time. :/

We use pure Swift (not Ceph backed radosgw) in our Undercloud. So I'm
not sure this would be a factor for us.

Dan

>
> Thanks,
> Kevin
> 
> From: Dan Prince [dpri...@redhat.com]
> Sent: Thursday, January 07, 2016 9:03 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] Is Swift a good choice of
> database for the TripleO API?
>
> On Tue, 2015-12-22 at 15:36 +, Dougal Matthews wrote:
> > Hi all,
> >
> > This topic came up in the 2015-12-15 meeting[1], and again briefly
> > today.
> > After working with the code that came out of the deployment library
> > spec[2] I
> > had some concerns with how we are storing the templates.
> >
> > Simply put, when we are dealing with 100+ files from tripleo-heat-
> > templates
> > how can we ensure consistency in Swift without any atomicity or
> > transactions.
> > I think this is best explained with a couple of examples.
> >
> >  - When we create a new deployment plan (upload all the templates
> > to
> > swift)
> >how do we handle the case where there is an error? For example,
> > if
> > we are
> >uploading 10 files - what do we do if the 5th one fails for some
> > reason?
> >There is a patch to do a manual rollback[3], but I have concerns
> > about
> >doing this in Python. If Swift is completely inaccessible for a
> > short
> >period the rollback wont work either.
>
> Would Swift's Bulk middleware help us here:
>
> https://github.com/openstack/swift/blob/master/swift/common/middlewar
> e/
> bulk.py
>
> We don't currently have that middleware enabled but we certainly
> could
> try it out. NOTE the "Expand tar files into a swift account"
> feature...
>
> Dan
>
> >
> >  - When deploying to Heat, we need to download all the YAML files
> > from Swift.
> >This can take a couple of seconds. What happens if somebody
> > starts
> > to
> >upload a new version of the plan in the middle? We could end up
> > trying to
> >deploy half old and half new files. We wouldn't have a
> > consistent
> > view of
> >the database.
> >
> > We had a few suggestions in the meeting:
> >
> >  - Add a locking mechanism. I would be concerned about deadlocks or
> > having to
> >lock for the full duration of a deploy.
> >  - Store the files in a tarball (so we only deal with one file). I
> > think we
> >could still hit issues with multiple operations unless we
> > guarantee that
> >only one instance of the API is ever running.
> >
> > I think these could potentially be made to work, but at this point
> > are we
> > using the best tool for the job?
> >
> > For alternatives, I see a can think of a couple of options:
> >
> > - Use a database, like we did for Tuskar and most OpenStack API's
> > do.
> > - Invest time in building something on Swift.
> > - Glance was transitioning to be a Artifact store. I don't know the
> > status of
> >   this or if it would meet out needs.
> >
> > Any input, ideas or suggestions would be great!
> >
> > Thanks,
> > Dougal
> >
> >
> > [1]: http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.2
> > 01
> > 5-12-15-14.03.log.html#l-89
> > [2]: https://specs.openstack.org/openstack/tripleo-specs/specs/mita
> > ka
> > /tripleo-overcloud-deployment-library.html
> > [3]: https://review.openstack.org/#/c/257481/
> > ___
> > __
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bs
> > cribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

[Jay Pipes]

On 01/07/2016 06:42 PM, Jim Rollenhagen wrote:

On Thu, Jan 07, 2016 at 03:32:39PM -0500, Jay Pipes wrote:

On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:

On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:

On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:

Hi all,

A change to global-requirements[1] introduces mimic, which is an http
server that can mock various APIs, including nova and ironic, including
control of error codes and timeouts. The ironic team plans to use this
for testing python-ironicclient without standing up a full ironic
environment.

Here's the catch - mimic is built on twisted. I know twisted was
previously removed from OpenStack (or at least people said "pls no", I
don't know the full history). We didn't intend to stealth-introduce
twisted back into g-r, but it was pointed out to me that it may appear
this way, so here I am letting everyone know. lifeless pointed out that
when tests are failing, people may end up digging into mimic or twisted
code, which most people in this community aren't familiar with AFAIK,
which is a valid point though I hope it isn't required often.

So, the primary question here is: do folks have a problem with adding
twisted here? We're holding off on Ironic changes that depend on this
until this discussion has happened, but aren't reverting the g-r change
until we decide one way or another.

// jim

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


What is the advantage of running another server like this over using
requests-mock (which is used by other OpenStack projects for testing
today)? The only difference here seems to be that you actually execute
requests code in one case and not in the other.

Requests-mock debugging when things go wrong seems a bit simpler.

This is less about twisted and more about trying to not introduce yet
another way to mock code in the tree that people need to understand.

-Sean


We'd be using this for functional tests, not unit, where we can't really
inject mocks. The idea is that we could run a full functional suite
against either mimic or a full ironic environment, just by changing a
test setting.


I don't really see the point of a separate project like Mimic that has a
whole bunch of reimplementations (mocked out) of all sorts of OpenStack (and
RAX-specific) API services. It's just a great way to introduce a larger
surface area for bugs to creep in -- since you have to keep the Mimic
interfaces up to date with the real interfaces. Better to keep something
like this -- if it is TRULY needed -- in-tree with the API service itself,
so that the chances of divergence are reduced. This is similar to the
fakevirt driver in Nova. It's in tree for good reason: when someone changes
the virt driver interface, the fakevirt driver goes boom and needs to be
changed in a corresponding fashion in the same patch.


I tend to think our REST APIs are much more stable than internal python
APIs, and so we can manage the divergence much easier.

Also, mimic can simulate:

* old versions (less needed with all the microversion stuff)
* old bugs that were shipped
* misconfigurations
* networking errors
* the passage of time (including timeouts)

We probably don't want to keep a catalog of old bugs and misconfigurations in
tree forever.


What value does a functional test against an HTTP API service that does
nothing (other than introduce greater surface area for bugs) actually offer
over unit tests anyway?


Testing the full stack of the client instead of mocking the bottom
half of requests is a big one.

Lekha and Glyph gave a talk on Mimic in Paris; it may be enlightening.
https://www.youtube.com/watch?v=HKUUQme3dwA


OK, I just watched that. Sorry, still don't see the value that Mimic 
provides over unit testing the client interfaces and mocking out the 
HTTP payloads so you have strict control over the expectations.


The problem that Glyph noted in the video about the unit test that 
mocked out os.chdir to improperly return a value isn't solved whatsoever 
by Mimic, so I find it odd that that example was used in discussing the 
value of Mimic. Bad mocks are just that: bad mocks. The same false 
positive failure could easily be introduced with a typo in the "metadata 
injection" that Mimic does to inject failures into the system.


Mimic isn't testing anything on the server side at all so I'm not sure 
why folks call it "integration testing". It isn't testing the 
integration of anything at all. All it enables is multi-language client 
library testing, and see my response to Ben, the surface area it 
introduces for bugs in the test platform itself in my opinion outweigh 
the multi-language value it might have.


Final question on this... if Mimic is *only* for testing clients, why 
not make it just a dependency for python-ironicclient and not ironic itself?


Best,
-jay

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

Re: [openstack-dev] [Openstack-dev][Manila] status=NONE when share is created

[Shinobu Kinjo]

Hello,

It's better to discuss this on IRC.

https://wiki.openstack.org/wiki/IRC

Rgds,
Shinobu


On Thu, Jan 7, 2016 at 4:11 PM,  wrote:

> Hi All,
>
>
>
> Could someone please reply to the mail below ..
>
>
>
> Is this an expected state to get created share status as None?
>
>
>
> As we are intentionally not creating “share instance” while creating
>
> share..
>
>
>
> For details please see mail below..
>
>
>
> Thanks
>
> Nidhi
>
>
>
>
>
> *From:* Nidhi Mittal Hada (WT01 - Product Engineering Service)
> *Sent:* Wednesday, January 06, 2016 1:23 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [Openstack-dev][Manila] status=NONE when share is created
>
>
>
> Hi All,
>
>
>
> https://bugs.launchpad.net/manila/+bug/1526284
>
>
>
> stack@controller:~/devstack$ manila create NFS 1 --name share5
> --share-type GENERAL_Storage
> +-+--+
> | Property | Value |
> +-+--+
> |
> *status | None
> > 
> 
> | *| share_type_name | GENERAL_Storage |
> | description | None |
> | availability_zone | None |
> | share_network_id | None |
> | export_locations | [] |
> | share_server_id | None |
> | host | None |
> | snapshot_id | None |
> | is_public | False |
> | task_state | None |
> | snapshot_support | True |
> | id | 6572a26a-2313-4a1d-8765-4a031ec0ae3a |
> | size | 1 |
> | name | share5 |
> | share_type | 961b767b-b8e4-4769-884f-7214af944f29 |
> | created_at | 2015-12-15T11:31:23.818642 |
> | export_location | None |
> | share_proto | NFS |
> | consistency_group_id | None |
> | source_cgsnapshot_member_id | None |
> | project_id | 0e15488bc7a14ce5b530920c95357457 |
> | metadata | {} |
> +-+--+
>
> *status should be “creating”.. but it’s being shown as “NONE” which is not
> right.*
>
> I am working on this bug. I have a doubt. code is as below.
>
> In file manila/share/api.py
>
>
>
> try:
>
> 234* share = self.db.share_create(context, options,*
>
> *235
> create_share_instance=False)>>*
>
> 236 QUOTAS.commit(context, reservations)
>
> 237 except Exception:
>
> 238 with excutils.save_and_reraise_exception():
>
> 239 try:
>
> 240 self.db.share_delete(context, share['id'])
>
> 241 finally:
>
> 242 QUOTAS.rollback(context, reservations)
>
>
> 
>
>
>
> Where we are intentionally giving *create_share_instance=False that means
> in db function *
>
> *share_create(), share Instance will not be created And status is a field
> in share_instances table only. *
>
>
>
> *Hence it will come as “None” only till instance is created.*
>
>
>
> Is this an “intentional step” to show status as “None”..
>
>
>
> is this bug not valid?
>
>
>
> *Please suggest.*
>
>
>
>
> *Thanks Nidhi*
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> __
> 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
>
>


-- 
Email:
shin...@linux.com
GitHub:
shinobu-x 
Blog:
Life with Distributed Computational System based on OpenSource

__
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][bugs] help needed: volunteers for bug skimming (1 week)

[Markus Zoeller]

The bug triage is an important first step to improve the quality
of Nova. Every code contributor should be aware of it and can 
contribute without any special permissions [1]. We need more 
volunteers to do this. If you want to be one of them for 1 week, 
raise your hand in this thread or add your name in the wiki [2]. 
At best we will have at least 1 person until today's Nova meeting 
at 21:00 UTC [3]. When you volunteer, I will be available in IRC 
for requests, too.

Regards, Markus Zoeller (markus_z)

References:
[1] 
https://wiki.openstack.org/wikiBugTriage#Task_1:_Confirm_new_bugs_.28anyone.29
[2] 
https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
[3] https://wiki.openstack.org/wiki/Meetings/Nova


__
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][libvirt] Deprecating the live_migration_flag and block_migration_flag config options

[Sahid Orentino Ferdjaoui]

On Mon, Jan 04, 2016 at 09:12:06PM +, Mark McLoughlin wrote:
> Hi
> 
> commit 8ecf93e[1] got me thinking - the live_migration_flag config
> option unnecessarily allows operators choose arbitrary behavior of the
> migrateToURI() libvirt call, to the extent that we allow the operator
> to configure a behavior that can result in data loss[1].
> 
> I see that danpb recently said something similar:
> 
>   https://review.openstack.org/171098
> 
>   "Honestly, I wish we'd just kill off  'live_migration_flag' and
>   'block_migration_flag' as config options. We really should not be
>   exposing low level libvirt API flags as admin tunable settings.
> 
>   Nova should really be in charge of picking the correct set of flags
>   for the current libvirt version, and the operation it needs to
>   perform. We might need to add other more sensible config options in
>   their place [..]"

Nova should really handle internal flags and this serie is running in
the right way.

> ...

>   4) Add a new config option for tunneled versus native:
> 
>    [libvirt]
>    live_migration_tunneled = true
> 
>  This enables the use of the VIR_MIGRATE_TUNNELLED flag. We have 
>      historically defaulted to tunneled mode because it requires the 
>      least configuration and is currently the only way to have a 
>      secure migration channel.
> 
>      danpb's quote above continues with:
> 
>        "perhaps a "live_migration_secure_channel" to indicate that 
>         migration must use encryption, which would imply use of 
>         TUNNELLED flag"
> 
>      So we need to discuss whether the config option should express the
>      choice of tunneled vs native, or whether it should express another
>      choice which implies tunneled vs native.
> 
>        https://review.openstack.org/263434

We probably have to consider that operator does not know much about
internal libvirt flags, so options we are exposing for him should
reflect benefice of using them. I commented on your review we should
at least explain benefice of using this option whatever the name is.

>   5) Add a new config option for additional migration flags:
> 
>    [libvirt]
>    live_migration_extra_flags = VIR_MIGRATE_COMPRESSED
> 
>  This allows operators to continue to experiment with libvirt behaviors
>  in safe ways without each use case having to be accounted for.
> 
>https://review.openstack.org/263435
> 
>  We would disallow setting the following flags via this option:
> 
>    VIR_MIGRATE_LIVE
>    VIR_MIGRATE_PEER2PEER
>    VIR_MIGRATE_TUNNELLED
>    VIR_MIGRATE_PERSIST_DEST
>    VIR_MIGRATE_UNDEFINE_SOURCE
>    VIR_MIGRATE_NON_SHARED_INC
>    VIR_MIGRATE_NON_SHARED_DISK
> 
> which would allow the following currently available flags to be set:

>    VIR_MIGRATE_PAUSED
>    VIR_MIGRATE_CHANGE_PROTECTION
>    VIR_MIGRATE_UNSAFE
>    VIR_MIGRATE_OFFLINE
>    VIR_MIGRATE_COMPRESSED
>    VIR_MIGRATE_ABORT_ON_ERROR
>    VIR_MIGRATE_AUTO_CONVERGE
>    VIR_MIGRATE_RDMA_PIN_ALL

We can probably consider to provide VIR_MIGRATE_PAUSED and
VIR_MIGRATE_COMPRESSED as dedicated options too ?

__
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] [infra][stackalytics] some projects not visible in stackalytics now

[Shake Chen]

seem some project not update many day.like

http://stackalytics.com/?project_type=openstack=kolla-group

the data still stay 02 Jan 2016

On Thu, Jan 7, 2016 at 5:02 PM, joehuang  wrote:

> Hello,
>
>
>
> Both Kingbird[1] and Tricircle[2] are not visible in stackalytics.com
> now, which are projects under OpenStack name space.  Some days ago these
> two projects are listed in
> http://stackalytics.com/?project_type=openstack-others
>
>
>
> Maybe I missed some mail, don’t know what happened, or something wrong in
> configuration in Infra or stackalytics?
>
>
>
> [1] https://github.com/openstack/kingbird/
>
> [2] https://github.com/openstack/tricircle
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
> __
> 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
>
>


-- 
Shake Chen
__
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] [senlin] Midcycle meetup (2016-01-11/12)

[Zhipeng Huang]

do we have audio communication for the meetup ?

On Mon, Jan 4, 2016 at 4:41 PM, Ethan Lynn  wrote:

> Finally I get a chance to see you all!
>
> Best Regards,
> Ethan Lynn
>
>
>
> On Dec 28, 2015, at 17:54, Yanyan Hu  wrote:
>
> Great! Can't wait to see you guys :)
>
> 2015-12-28 10:03 GMT+08:00 Qiming Teng :
>
>> Dear all,
>>
>> Wish you all a merry christmas and a happy new year.
>>
>> Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
>> it goes beyond just a meetup between developers. We are inviting some
>> users to share their real-life use cases and requirements.
>>
>> IBM Research China Lab will host the event. Please find the schedule
>> etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle
>>
>> Any comments/suggestions are welcomed. We are looking forward to see you
>> guys.
>>
>> Regards,
>>   Qiming
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Best regards,
>
> Yanyan
> __
> 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
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

[Doug Hellmann]

Excerpts from Kendall J Nelson's message of 2016-01-06 13:27:14 -0600:
> Yeah something like that- I'm new to the process so I may have the
> terminology wrong. So far I have Martin Hickey and Matt Kassawara and
> myself. I was hoping to get someone from Nova and maybe someone from
> Keystone as well.

OK. The summits are split between normal conference
presentation-in-front-of-an-audience style tracks (including things
like panel discussions) and "design session" tracks which are
discussions among contributors. What you're proposing would fit
better into a design session, where we could have a conversation
with our goal being something like plans for better documentation
for using the config generator based on some agreed best practices.
I would participate in a discussion like that, if my schedule at
the summit permits me to.

On the other hand, so far I'm only hearing that Cinder has requirements
that are not being met by the tool, so I will repeat my request
that you document them in more detail somehow (this email thread
would be a good start) so we can all understand the needs. It's
entirely possible we can resolve this issue before the summit.

Doug

> 
> All the Best,
>   
>Kendall J. Nelson  
>Software Engineer &
>OpenStack Contributor  
>   
> 
> 
>
>
>
>E-mail: kjnel...@us.ibm.com IBM 
>Cell Phone: (952) 215- 4025 
>IRC Nickname: diablo_rojo 3605 Hwy 52 N 
>  Rochester, MN 
> 55901-1407 
>  United States 
>
> 
> 
> 
> 
> 
> 
> From:Doug Hellmann 
> To:openstack-dev 
> Date:01/06/2016 01:22 PM
> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
> Sample Configuration Option Files
> 
> Excerpts from Kendall J Nelson's message of 2016-01-06 13:07:30 -0600:
> > Hey Doug,
> >
> > This definitely sounds like something to look into. Would you be
> > interested in being a part of a panel at the upcoming summit in Austin to
> > discuss this?
> 
> I'm not sure what you mean by "panel." Are you planning a cross-project
> design session?
> 
> Doug
> 
> >
> > All the Best,
> >
> >Kendall J. Nelson
> >Software Engineer &
> >OpenStack Contributor
> >
> >
> >
> >
> >
> >
> >E-mail: kjnel...@us.ibm.com IBM
> >Cell Phone: (952) 215- 4025
> >IRC Nickname: diablo_rojo 3605 Hwy 52 N
> >  Rochester, MN
> > 55901-1407
> >  United States
> >
> >
> >
> >
> >
> >
> >
> > From:Doug Hellmann 
> > To:openstack-dev 
> > Date:01/06/2016 01:03 PM
> > Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation
> of
> > Sample Configuration Option Files
> >
> > Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
> > > Ben,
> > >
> > > Please see my in-line responses ...
> > >
> > > On 01/04/2016 05:43 PM, Ben Nemec wrote:
> > > > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> > > >> Hello,
> > > >>
> > > >>
> > > >> In brainstorming ideas for talks at the upcoming summit, I thought
> > about
> > > >> some of the things I had worked on for Cinder and what could still
> be
> > > >> improved. One of the things I have been looking into is the
> generation
> > > >> of sample configuration option files. Upon initial research it looks
> > > >> like none of the main projects are doing it the same way.
> > > > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and
> Heat
> > > > (at least) are all using the oslo-config-generator tool for this.
> > There
> > > > might be some slight variation in how they call it, but they are
> using
> > it.
> > > Yes, we know that they are all using oslo-config-generator but there is
> > > not consistency
> > > in how the information that oslo-config-generator needs to do its job
> is
> > > being created.
> > > Kendall is looking to better understand what we should be doing and try
> > > to bring
> > > greater consistency between the projects.
> > >
> > > > I only vaguely recall having discussions about this with Cinder, so
> I'd
> > > > be interested in a refresher around why Cinder didn't want to do it
> 

Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

[Victoria Martínez de la Cruz]

A big +1.

Thanks Amrith and Mariam!

2016-01-06 17:03 GMT-03:00 Peter Stachowski :

> I agree!
>
> +1
>
> Peter
>
> -Original Message-
> From: Vyvial, Craig [mailto:craig.vyv...@hpe.com]
> Sent: January-06-16 2:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core
>
> Thanks for the nomination Amrith and I think Mariam will be a great
> addition to the core team.
>
> +1
>
> -Craig
>
> On Jan 6, 2016, at 12:39 PM, Amrith Kumar > wrote:
>
> Members of the Trove team,
>
> I would like to nominate Mariam John (johnma on IRC) to the Trove core
> review team.
>
> Mariam has been an active member of the Trove team for some time now. She
> added support for IBM DB2 in Trove and provided elements for building Trove
> guest images. She also implemented code that provided CouchDB support in
> Trove. She has been an active reviewer and I have found her review comments
> to be insightful and useful.
>
> You can review her activity report at
>
> http://stackalytics.com/report/users/mariamj
>
> Members of the Trove core team, please reply to this message with your
> feedback to this proposed change.
>
> Thanks,
>
> -amrith
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 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] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

[Davanum Srinivas]

Right, if there are changes needed in oslo-config-generator to make it
work better for cinder then we should just go the next step and
propose a spec as well. There's no need to wait for summit. We should
try to get to consensus and nail this thing really soon.

Thanks,
Dims

On Thu, Jan 7, 2016 at 9:55 AM, Doug Hellmann  wrote:
> Excerpts from Kendall J Nelson's message of 2016-01-06 13:27:14 -0600:
>> Yeah something like that- I'm new to the process so I may have the
>> terminology wrong. So far I have Martin Hickey and Matt Kassawara and
>> myself. I was hoping to get someone from Nova and maybe someone from
>> Keystone as well.
>
> OK. The summits are split between normal conference
> presentation-in-front-of-an-audience style tracks (including things
> like panel discussions) and "design session" tracks which are
> discussions among contributors. What you're proposing would fit
> better into a design session, where we could have a conversation
> with our goal being something like plans for better documentation
> for using the config generator based on some agreed best practices.
> I would participate in a discussion like that, if my schedule at
> the summit permits me to.
>
> On the other hand, so far I'm only hearing that Cinder has requirements
> that are not being met by the tool, so I will repeat my request
> that you document them in more detail somehow (this email thread
> would be a good start) so we can all understand the needs. It's
> entirely possible we can resolve this issue before the summit.
>
> Doug
>
>>
>> All the Best,
>>
>>Kendall J. Nelson
>>Software Engineer &
>>OpenStack Contributor
>>
>>
>>
>>
>>
>>
>>E-mail: kjnel...@us.ibm.com IBM
>>Cell Phone: (952) 215- 4025
>>IRC Nickname: diablo_rojo 3605 Hwy 52 N
>>  Rochester, MN
>> 55901-1407
>>  United States
>>
>>
>>
>>
>>
>>
>>
>> From:Doug Hellmann 
>> To:openstack-dev 
>> Date:01/06/2016 01:22 PM
>> Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation of
>> Sample Configuration Option Files
>>
>> Excerpts from Kendall J Nelson's message of 2016-01-06 13:07:30 -0600:
>> > Hey Doug,
>> >
>> > This definitely sounds like something to look into. Would you be
>> > interested in being a part of a panel at the upcoming summit in Austin to
>> > discuss this?
>>
>> I'm not sure what you mean by "panel." Are you planning a cross-project
>> design session?
>>
>> Doug
>>
>> >
>> > All the Best,
>> >
>> >Kendall J. Nelson
>> >Software Engineer &
>> >OpenStack Contributor
>> >
>> >
>> >
>> >
>> >
>> >
>> >E-mail: kjnel...@us.ibm.com IBM
>> >Cell Phone: (952) 215- 4025
>> >IRC Nickname: diablo_rojo 3605 Hwy 52 N
>> >  Rochester, MN
>> > 55901-1407
>> >  United States
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > From:Doug Hellmann 
>> > To:openstack-dev 
>> > Date:01/06/2016 01:03 PM
>> > Subject:Re: [openstack-dev] [all] Austin Summit Panel on Generation
>> of
>> > Sample Configuration Option Files
>> >
>> > Excerpts from Jay S. Bryant's message of 2016-01-05 13:55:30 -0600:
>> > > Ben,
>> > >
>> > > Please see my in-line responses ...
>> > >
>> > > On 01/04/2016 05:43 PM, Ben Nemec wrote:
>> > > > On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
>> > > >> Hello,
>> > > >>
>> > > >>
>> > > >> In brainstorming ideas for talks at the upcoming summit, I thought
>> > about
>> > > >> some of the things I had worked on for Cinder and what could still
>> be
>> > > >> improved. One of the things I have been looking into is the
>> generation
>> > > >> of sample configuration option files. Upon initial research it looks
>> > > >> like none of the main projects are doing it the same way.
>> > > > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and
>> Heat
>> > > > (at least) are all using the oslo-config-generator tool for this.
>> > There
>> > > > might be some slight variation in how they call it, but they are
>> using
>> > it.
>> > > Yes, we know that they are all using oslo-config-generator but there is
>> > > not consistency
>> > > in how the information that oslo-config-generator needs to do its job
>> is
>> > > being created.
>> > > Kendall is looking to better understand what we should be doing and try
>> > > to bring
>> > > greater consistency between the projects.
>> > >
>> > > > I only vaguely recall having discussions about this with Cinder, so
>> I'd
>> > > > be interested in a refresher around why Cinder didn't want to do it
>> the

Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

[Doug Shelley]

+1 thanks for stepping up Mariam.

From: Victoria Martínez de la Cruz 
>
Reply-To: OpenStack List 
>
Date: Thursday, January 7, 2016 at 7:52 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

A big +1.

Thanks Amrith and Mariam!

2016-01-06 17:03 GMT-03:00 Peter Stachowski 
>:
I agree!

+1

Peter

-Original Message-
From: Vyvial, Craig [mailto:craig.vyv...@hpe.com]
Sent: January-06-16 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

Thanks for the nomination Amrith and I think Mariam will be a great addition to 
the core team.

+1

-Craig

On Jan 6, 2016, at 12:39 PM, Amrith Kumar 
>>
 wrote:

Members of the Trove team,

I would like to nominate Mariam John (johnma on IRC) to the Trove core review 
team.

Mariam has been an active member of the Trove team for some time now. She added 
support for IBM DB2 in Trove and provided elements for building Trove guest 
images. She also implemented code that provided CouchDB support in Trove. She 
has been an active reviewer and I have found her review comments to be 
insightful and useful.

You can review her activity report at

http://stackalytics.com/report/users/mariamj

Members of the Trove core team, please reply to this message with your feedback 
to this proposed change.

Thanks,

-amrith

__
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-dev] [nova] nova gate Failure

[Jialiang Song]

Hello,


Some Failures were found by Gate in: https://review.openstack.org/264852
Can anybody help on how to proceed？

I have tried to resolve it following the below link but failed
http://docs.openstack.org/infra/manual/developers.html#automated-testing

Thanks in advance!


Best Regards,
Jialiang__
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] Temporarily remove swarm func test from gate

[Adrian Otto]

Hongbin,

I’m not aware of any viable options besides using a nonvoting gate job. Are 
there other alternatives to consider? If not, let’s proceed with that approach.

Adrian

> On Jan 7, 2016, at 3:34 PM, Hongbin Lu  wrote:
> 
> Clark,
> 
> That is true. The check pipeline must pass in order to enter the gate 
> pipeline. Here is the problem we are facing. A patch that was able to pass 
> the check pipeline is blocked in gate pipeline, due to the instability of the 
> test. The removal of unstable test from gate pipeline aims to unblock the 
> patches that already passed the check.
> 
> An alternative is to remove the unstable test from check pipeline as well or 
> mark it as non-voting test. If that is what the team prefers, I will adjust 
> the review accordingly.
> 
> Best regards,
> Honbgin
> 
> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org] 
> Sent: January-07-16 6:04 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum] Temporarily remove swarm func test from 
> gate
> 
> On Thu, Jan 7, 2016, at 02:59 PM, Hongbin Lu wrote:
>> Hi folks,
>> 
>> It looks the swarm func test is currently unstable, which negatively 
>> impacts the patch submission workflow. I proposed to remove it from 
>> Jenkins gate (but keep it in Jenkins check), until it becomes stable.
>> Please find the details in the review
>> (https://review.openstack.org/#/c/264998/) and let me know if you have 
>> any concern.
>> 
> Removing it from gate but not from check doesn't necessarily help much 
> because you can only enter the gate pipeline once the change has a +1 from 
> Jenkins. Jenkins applies the +1 after check tests pass.
> 
> Clark
> 
> __
> 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] [nova] nova gate Failure

[Matt Riedemann]

On 1/7/2016 9:36 PM, Jialiang Song wrote:

Hello,

Some Failures were found by Gate in: https://review.openstack.org/264852

Can anybody help on how to proceed？

I have tried to resolve it following the below link but failed
http://docs.openstack.org/infra/manual/developers.html#automated-testing


Thanks in advance!

Best Regards,
Jialiang




__
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



pep8 and unit tests failed. You should be running 'tox -r -e py27,pep' 
locally before pushing your changes up and fixing any of the failures 
before committing and pushing up for review.


--

Thanks,

Matt Riedemann


__
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] Docker Swarm and Kuryr Integration Demo

[Mohammad Banikazemi]

I have a demo video of Docker Swarm and Kuryr Integration posted here:
http://mbanikazemi.com/2016/01/07/docker-swarm-and-kuryr/

Best,

Mohammad




From:   Gal Sagie 
To: "OpenStack Development Mailing List (not for usage questions)"
, Eran Gampel
, Antoni Segura Puimedon
, Vikas Choudhary
, Irena Berezovsky
, Taku Fukushima ,
Mohammad Banikazemi/Watson/IBM@IBMUS, Kyle Mestery
, Jaume Devesa 
Date:   12/29/2015 01:37 AM
Subject:[Kuryr] Progress Update and Kubernetes Integration



Hello everyone,

Just wanted to give you all some progress update at what we have been doing
in Kuryr,
We conducted an IRC meeting today, you can see the logs here [1]

1) We got Docker pluggable IPAM support in Kuryr thanks to Vikas Choudhary,
there
   are still some small points to address but most of the code is already
merged.
   I plan to write a blog post about it describing the mechanism

2) Mohammad Banikazemi verified Kuryr works with Docker Swarm seamlessly
   and we are compatible with latest Docker libnetwork

3) We have fullstack job running in the gate, basically these tests are
running with a
    working Openstack environment with Kuryr deployed and using Neutron
client and
    Docker python client to simulate different scenarios and test Kuryr
functionality
    in addition to our unit tests.

4) We have Rally job running, we plan to contribute Docker plugin to Rally
and have
    some of the above tests run benchmarking operation, i think this is a
very important
    goal as it will also help us benchmark different Neutron backends and
solutions
    in terms of containers networking and let users/operators have better
comparison
    between their different options.

5) We are working on packaging for Kuryr (Thanks to Jaume Devesa for that)

6) We are working on investigating using Linux CAPABILITIES rather then
using
    rootwrap or running as root for Kuryr (Thanks to Antoni Segura
Puimedon)

We also decided to give Kubernetes integration higher priority and are now
brain storming
design options to integrate Kubernetes and Kuryr which means integrating
Kubernetes with Neutron (OpenStack networking abstraction).
If you have any idea in that area or done something similar (or in the
middle of doing it)
Please share it in this Etherpad [2].
Our goal is to expose the different ways to do this to the user and find
the best common
method.

We are also starting to approach the Kuryr-Magnum integration and nested
containers and
hope to achieve some progress on this by the end of the release.

Thanks everyone that contribute and help, its greatly appreciated by all of
us!
If you would like to join , feel free to step in our IRC channel at
freenode #openstack-kuryr
Join the IRC meeting [3] or just email me with any question/idea.

Thanks
Gal.

[1]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-29-03.01.html

[2] https://etherpad.openstack.org/p/kuryr_k8s
[3] https://wiki.openstack.org/wiki/Meetings/Kuryr
__
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] [openstacksdk][nose] Namespace conflict?

[Qiming Teng]

Thanks, Doug. Will keep an eye on this see if it is just an error made
by myself.

- Qiming


__
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] [sriov] Could create sriov vm on one host successfully but failed on another host

[yujie]

Hi all,
  I have two hosts. Host1 run services of controller/compute/network, 
and host2 run services of compute. The network type is vlan.
  When creating port with direct type and booting a vm using this port 
on host2, the vm works well. But when create the vm on host1 using same 
way, the vm state is error. And the nova-compute log says:


ERROR nova.pci.stats [req-4af9b36d-8a0c-43d5-8535-fbf9e8d1b857 
06172a48a7254dda934a729f4a58d2ec 894880b2f31046d7b8a83bc3783df070 - - -] 
Failed to allocate PCI devices for instance. Unassigning devices back to 
pools. This should not happen, since the scheduler should have accurate 
information, and allocation during claims is controlled via a hold on 
the compute node semaphore


  Any suggestion will be grateful.
  Thanks.

  Yu


__
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] [infra][stackalytics] some projects not visible in stackalytics now

[Jay Pipes]

Hi everyone, and happy New Year!

Ilya and a number of other Mirantis folks are currently on holiday until 
the 10th. I'm sure he will address the issues promptly upon his return.


All the best,
-jay

On 01/07/2016 09:34 AM, Michał Dulko wrote:

On 01/07/2016 02:59 PM, Shake Chen wrote:

seem some project not update many day.like

http://stackalytics.com/?project_type=openstack=kolla-group

the data still stay 02 Jan 2016



And I can report that for some users (like me [1]) actions are not
tracked since the beginning of 2016. I can assure that I've did quite a
few reviews and got some patches merged.

[1]
http://stackalytics.com/?metric=marks=mitaka_id=michal-dulko-f

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



__
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] [neutron] [oslo] [cliff] Serious bug in puppet neutron cli json output parsing.

[Sofer Athlan-Guyot]

Akihiro Motoki  writes:

> I added 'oslo' and 'cliff' subject tag as well.
>
> 2015-12-31 1:37 GMT+09:00 Sofer Athlan-Guyot :
>> Hi,
>>
>> I have added neutron people as they may help to find a solution.
>>
>> After banging my head against the wall for a whole afternoon I
>> discovered a serious bug in puppet neutron module.
>>
>> I not going to repeat here the detail of the bug report[1].  Basically:
>>  - neutron_port
>>  - neutron_subnet
>>  - neutron_router
>>  - neutron_network
>>
>> may break idempotency randomly and won't work at all when clifftablib is
>> removed from the package dependency of python-openstackclient
>> (Mitaka[2])
>>
>> So the problem is that neutron cli json output on liberty (at least, and
>> maybe before) is not consistent and may come from cliff or clifftablib.
>> I didn't test it but the same may apply to openstack cli. As we don't
>> use the openstack cli json output it's not a issue (for puppet modules)
>
> Apparently the problem comes from the fact the JSON output from
> cliff 1.15.0 and cliff-tablib are different.

Yes indeed.  One is a clean JSON (cliff), the other is a JSON "table"
with "Field" and "Value" as key for every parameter.

>
> Another tricky point is that we have two entry points with a single name.
> If we install cliff 1.15.0 and cliff-tablib, we will see two json and two yaml
> formatters in the help message

Yes.  The problem being that whichever comes first win.  It's usually
clifftab, but no guaranty.

>
>> The available solution I can see are:
>>  1. go back to parsing csv, shell output (revert [3])
>>  2. find a way to leverage openstacklib parsing for neutron as well
>>  3. keep json and parse the right output (cliff) and find a way to make
>> sure that it is always used by stevedore
>>  4. ?
>
> A variation of option 3 is to release a new version of cliff-tablbi
> without  json and yaml formatter.
> cliff 1.15.0 and later supports JSON and YAML formatters,
> so there is no need that cliff-tablib supports them.
>

Actually the clifftab dependency comes from openstackcli.  This will be
completly remove in Mitaka.  Packager will adjust then I guess.

> When cliff 1.14.0 is used in some distribution, we can use the current version
> of cliff-tablib. If someone uses the latest versions, he can use cliff
> 1.15.0 and
> a new cliff-tablib without json and yaml formatters.
> I believe it helps this confusing situation in liberty.
>
>> From my point of view 3) is not a option, but other may disagree.
>
> My vote is option 3. cliff (or neutronclient as workaround) can ensure
> that either of cliff json formatter is chosen if two json formatters
> are available.

Hum,  not sure I get this right.  neutronclient will get what stevedore
gives him as formatter and it cannot be "set" at run time.  You have to
edit file and disable the json output you don't like.  Not something
neutronclient can do.

> However, I don't think it is a good idea that neutronclient cannot
> provide cliff-tablib version
> of JSON formatter if cliff 1.15.0 is installed.

This double negation with conditional lost me :) You mean that it if
cliff 1.15.0 is installed then neutronclient should use cliff-tablib ?

> Can puppet-neutron can handle the difference?

Well, the problem is that we have to check the output of the cli for
warning or the like that get mixed with the actual output.  So we rely
on a starting tag.  This tag is different if cliff - a plain "{" - or
clifftab - a "[{" - is used (on a limited set of test I did, there could
be more subtleties here).  Then we have to maintain two parsers one for
clifftab and one for cliff.  The more I think about it the less I can
see a proper way to maintain this.

Then there is the fact that the clifftab JSON output is not the expected
one.


For the record I end up reverting the patch[1] (solution 1) and adding
the code to filter the output[2] (which was the original motivation for
switching to json).  It was fast, didn't have anything to handle on the
json side and seems to work ok.

[1] https://review.openstack.org/262809
[2] https://review.openstack.org/263874

>
> Akihiro
>
>>
>> The problem is tricky and the fact that the CI cannot detect this is
>> trickier[4].
>>
>> So before Mitaka, the json parsing should go.  I would love to see an
>> interface that all puppet modules would use (solution 2).  The current
>> openstacklib parses openstack client well enough.  The neutron command
>> is not that different and I think there is space for code reuse.  This
>> would be a long term solution.  It would bring the advantage of having
>> only one interface to change if it was decided to use the API directly
>> for instance[5]
>>
>> In the meantime, a quick solution to this bug must be found.
>>
>> Looking forward to your comments.
>>
>> Regards,
>>
>> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
>> [2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
>> [3] 

Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

[Andrew Woodward]

On Tue, Dec 29, 2015 at 5:35 AM Sergii Golovatiuk 
wrote:

> Hi,
>
> Let me comment inline.
>
>
> On Mon, Dec 28, 2015 at 7:06 PM, Andrew Woodward  wrote:
>
>> In order to ensure that LVM can be configured as desired, its necessary
>> to purge them and then reboot the node, otherwise the partitioning commands
>> will most likely fail on the next attempt as they will be initialized
>> before we can start partitioning the node. Hence, when a node is removed
>> from the environment, it is supposed to have this data destroyed. Since
>> it's a running system, the most effective way was to blast the first 1Mb of
>> each partition. (with out many more reboots)
>>
>> As to the fallback to SSH, there are two times we use this process, with
>> the node reboot (after cobbler/IBP finishes), and with the wipe as we are
>> discussing here. These are for the odd occurrences of the nodes failing to
>> restart after the MCO command. I don't think anyone has had much success
>> trying to figure out why this occurs, but I've seen nodes get stuck in
>> provisioning and remove in multiple environments using 6.1 where they
>> managed to break the SSH Fallback. It would occur around 1/20 nodes
>> seemingly randomly. So with the SSH fallback I nearly never see the failure
>> in node reboot.
>>
>
> If we talk about 6.1-7.0 release there shouldn't be any problems with mco
> reboot. SSH fallback must be deprecated at all.
>

As I noted, I've see several 6.1 deployments where it was needed, I'd
consider it still very much in use. In other cases it might be necessary to
attempt to deal with a node who's MCO agent is dead, IMO they should be
kept.


>>
>
>>
>
>>
>
>> On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz 
>> wrote:
>>
>>> On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov
>>>  wrote:
>>> > Hi,
>>> > We have faced the issue that nodes' disks are wiped after stop
>>> deployment.
>>> > It occurs due to the logic of nodes removing (this is old logic and
>>> it's not
>>> > actual already as I understand). This logic contains step which calls
>>> > erase_node[0], also there is another method with wipe of disks [1].
>>> AFAIK it
>>> > was needed for smooth cobbler provision and ensure that nodes will not
>>> be
>>> > booted from disk when it shouldn't. Instead of cobbler we use IBP from
>>> > fuel-agent where current partition table is wiped before provision
>>> stage.
>>> > And use disks wiping for insurance that nodes will not booted from disk
>>> > doesn't seem good solution. I want to propose not to wipe disks and
>>> simply
>>> > unset bootable flag from node disks.
>>>
>>
> Disks must be wiped as boot flag doesn't guarantee anything. If bootlag is
> not set, BIOS will ignore ignore the device in boot-order. More over, 2
> partitions may have bootflag or operator may set to skip boot-order in BIOS.
>
> >
>>> > Please share your thoughts. Perhaps some other components use the fact
>>> that
>>> > disks are wiped after node removing or stop deployment. If it's so,
>>> then
>>> > please tell about it.
>>> >
>>> > [0]
>>> >
>>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137
>>> > [1]
>>> >
>>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb
>>> >
>>>
>>> I thought the erase_node[0] mcollective action was the process that
>>> cleared a node's disks after their removal from an environment. When
>>> do we use the ssh_erase_nodes?  Is it a fall back mechanism if the
>>> mcollective fails?  My understanding on the history is based around
>>> needing to have the partitions and data wiped so that the LVM groups
>>> and other partition information does not interfere with the
>>> installation process the next time the node is provisioned.  That
>>> might have been a side effect of cobbler and we should test if it's
>>> still an issue for IBP.
>>>
>>
> Since we do not use classical provision anymore, we have mco connection
> all the time. During IBP we have it as part of bootstrap, after reboot, mco
> is still present so all actions should be done via mco.
>
>
>>
>>>
>>> Thanks,
>>> -Alex
>>>
>>> [0]
>>> https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb
>>>
>>> > Best regards,
>>> > Svechnikov Artur
>>> >
>>> >
>>> __
>>> > 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] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

[Mike Bayer]

On 01/07/2016 11:02 AM, Sean Dague wrote:
> On 01/07/2016 09:56 AM, Brant Knudson wrote:
>>
>>
>> On Thu, Jan 7, 2016 at 6:39 AM, Clayton O'Neill > > wrote:
>>
>> On Thu, Jan 7, 2016 at 2:49 AM, Roman Podoliaka
>> > wrote:
>> >
>> > Linux gurus please correct me here, but my understanding is that Linux
>> > kernel queues up to $backlog number of connections *per socket*. In
>> > our case child processes inherited the FD of the socket, so they will
>> > accept() connections from the same queue in the kernel, i.e. the
>> > backlog value is for *all* child processes, not *per* process.
>>
>>
>> Yes, it will be shared across all children.
>>
>> >
>> > In each child process eventlet WSGI server calls accept() in a loop to
>> > get a client socket from the kernel and then puts into a greenlet from
>> > a pool for processing:
>>
>> It’s worse than that.  What I’ve seen (via strace) is that eventlet
>> actually
>> converts socket into a non-blocking socket, then converts that
>> accept() into a
>> epoll()/accept() pair in every child.  Then when a connection comes
>> in, every
>> child process wakes up out of poll and races to try to accept on the the
>> non-blocking socket, and all but one of them fails.
>>
>> This means that every time there is a request, every child process
>> is woken
>> up, scheduled on CPU and then put back to sleep.  This is one of the
>> reasons we’re (slowly) moving to uWSGI.
>>
>>
>> I just want to note that I've got a change proposed to devstack that
>> adds a config option to run keystone in uwsgi (rather than under
>> eventlet or in apache httpd mod_wsgi), see
>> https://review.openstack.org/#/c/257571/ . It's specific to keystone
>> since I didn't think other projects were moving away from eventlet, too.
> 
> I feel like this is a confused point that keeps being brought up.
> 
> The preferred long term direction of all API services is to be deployed
> on a real web server platform. It's a natural fit for those services as
> they are accepting HTTP requests and doing things with them.
> 
> Most OpenStack projects have worker services beyond just an HTTP server.
> (Keystone is one of the very few exceptions here). Nova has nearly a
> dozen of these worker services. These don't naturally fit as wsgi apps,
> they are more traditional daemons, which accept requests over the
> network, but also have periodic jobs internally and self initiate
> actions. They are not just call / response. There is no long term
> direction for these to move off of eventlet.

This is totally speaking as an outsider without taking into account all
the history of these decisions, but the notion of "Python + we're a
daemon" == "we must use eventlet" seems a little bit rigid.  Also, the
notion of "we have background tasks" == "we cant run in a web server",
also not clear.  If a service intends to serve HTTP requests, that
portion of that service should be deployed in a web server; if the
system has other "background tasks", ideally those are in a separate
daemon altogether, but also even if you're under something like
mod_wsgi, you can spawn a child process or worker thread regardless.
You always have a Python interpreter running and all the things it can do.

> 
>   -Sean
> 

__
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][nova] python-novaclient release 3.2.0 (mitaka)

[doug]

We are satisfied to announce the release of:

python-novaclient 3.2.0: Client library for OpenStack Compute API

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

For more details, please see below and:

https://launchpad.net/python-novaclient/+milestone/3.2.0

Please report issues through launchpad:

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


Changes in python-novaclient 3.1.0..3.2.0
-

06be50b Use assertTrue/False instead of assertEqual(T/F)
f9f9a46 Add python 2.7 comment
48c9a91 Fix extension loading from python path on Python 2.7
2283b46 Wrong usage of "a/an"
8f32031 Fix help strings
dd6b3cd Validate the fixed ip address passed with --nic
fd450d8 [microversions] share one object for shell arguments
84c3cac Put py34 first in the env order of tox
9cd9adb Fixed test_shell which can't test microversions>=2.4
fecf833 Updated from global requirements
cb7b496 document search_opts parameter
01961d6 Cleanup needless code from oslo-incubator
bbdedc6 Validation for arguments of list command passed by "--fields"
b6e44f8 Fix a Typo in Docstring

Diffstat (except docs and test files)
-

novaclient/api_versions.py |  10 +-
novaclient/base.py | 145 +-
novaclient/client.py   |   3 +
novaclient/exceptions.py   |   2 +-
novaclient/extension.py|   3 +-
novaclient/openstack/common/_i18n.py   |  45 --
novaclient/openstack/common/apiclient/__init__.py  |   0
novaclient/openstack/common/apiclient/auth.py  | 234 -
novaclient/openstack/common/apiclient/base.py  | 533 -
novaclient/openstack/common/apiclient/client.py| 388 ---
.../openstack/common/apiclient/exceptions.py   | 479 --
.../openstack/common/apiclient/fake_client.py  | 189 
novaclient/openstack/common/apiclient/utils.py | 100 
novaclient/openstack/common/cliutils.py| 260 +-
novaclient/shell.py|  52 +-
novaclient/utils.py|  92 +++-
novaclient/v2/contrib/instance_action.py   |   2 +-
novaclient/v2/contrib/tenant_networks.py   |   2 +-
novaclient/v2/servers.py   |  20 +-
novaclient/v2/shell.py |  72 ++-
openstack-common.conf  |   8 -
test-requirements.txt  |   2 +-
tox.ini|   2 +-
29 files changed, 383 insertions(+), 2339 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 8ffcf36..de8e472 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -19 +19 @@ testtools>=1.4.0
-tempest-lib>=0.11.0
+tempest-lib>=0.12.0



__
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-dev][Manila] status=NONE when share is created

[Ben Swartzlander]

On 01/06/2016 02:53 AM, nidhi.h...@wipro.com wrote:

Hi All,

https://bugs.launchpad.net/manila/+bug/1526284

(snip)

Where we are intentionally giving *create_share_instance=False that
means in db function *


I think I agree it would make more sense to create the first instance at 
the same time we create the share. I'd have to look at the code to see 
if there's a good reason for doing it later on.


As Shinobu suggests, though, this would probably better be handled on 
IRC or in a code review.


-Ben



*share_create(), share Instance will not be created And status is a
field in share_instances table only. *

**

*Hence it will come as “None” only till instance is created.*

**

Is this an “intentional step” to show status as “None”..

is this bug not valid?



__
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] [Horizon] naming of Javascript bits

[Richard Jones]

Yep, thanks folks. Apart from the existing styleguide arguing with my
preferred approach, it seems like we agree on something that should be
pretty consistent. Thanks for putting up that consistency patch Rajat.

On 8 January 2016 at 06:49, Rajat Vig  wrote:

> I created a patch based off what Richard used as an example to highlight
> inconsistencies and made it consistent.
>
> https://review.openstack.org/#/c/264942/
>
> Have a look and if it feels fine, we can start changing what else exists
> on similar lines.
> Suggestions welcome.
>
> -Rajat
>
> On Thu, Jan 7, 2016 at 10:14 AM Thai Q Tran  wrote:
>
>> I 2nd that, should rename the file to delete.service.js to match service
>> name.
>>
>>
>> - Original message -
>> From: Rajat Vig 
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Cc:
>> Subject: Re: [openstack-dev] [Horizon] naming of Javascript bits
>> Date: Thu, Jan 7, 2016 12:03 AM
>>
>> Richard
>>
>> My preference is the same as what you've got there.
>> Fully namespaced Services and Controller allow for better reusability and
>> possibly maintainability.
>> If all "deleteService" were named just that, it'll be mighty confusing to
>> use it in other places.
>>
>> With regards to tying the folder path and the Service/Controller I'd
>> mostly go with that as that encourages simpler rules on how to namespace.
>>
>> For the particular patch you mentioned, the namespaces had a bit of churn
>> which is sort of reflected in what exists in the patch now.
>>
>> If we decide a convention, then we can go and change the bits when the
>> files change next.
>>
>> -Rajat
>>
>>
>>
>> On Wed, Jan 6, 2016 at 10:30 PM Richard Jones 
>> wrote:
>>
>> Hi Horizon folks,
>>
>> We've been pretty good about namespacing the new angular code (to the
>> extreme of having a bunch of very similar module files littered around, but
>> that's angular/JS for you, so I'm not going to go on about it ).
>>
>> Anyhoo. One thing I've noticed is that the services, factories and
>> controllers inside those modules aren't being consistently named. We have
>> got a mix of:
>>
>> Launch Instance:
>>
>>   .module('horizon.dashboard.project.workflow.launch-instance')
>>   .factory('launchInstanceModel', launchInstanceModel);
>>
>> The new Images panel:
>>
>>   .module('horizon.app.core.images')
>>   .factory('horizon.app.core.images.row-actions.service', rowActions);
>>
>> and in the same patch:
>>
>>   .module('horizon.app.core.images')
>>   .factory('horizon.app.core.images.actions.deleteService',
>> deleteService);
>>
>> I actually prefer the second form because it matches the filename
>> ("row-actions.service.js") even though the module namespace doesn't match
>> the file path ("/static/app/core/images/table/").
>>
>> Your thoughts?
>>
>>
>>  Richard
>> __
>> 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] [all] re-introducing twisted to global-requirements

[Ian Cordasco]

-Original Message-
From: David Stanek 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: January 7, 2016 at 18:14:23
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] re-introducing twisted to   
global-requirements

> On Thu, Jan 7, 2016 at 3:01 PM, Jim Rollenhagen  
> wrote:
>  
> > We'd be using this for functional tests, not unit, where we can't really
> > inject mocks. The idea is that we could run a full functional suite
> > against either mimic or a full ironic environment, just by changing a
> > test setting.
> >
>  
> I'm assuming that this would be for client functional tests because it
> wouldn't make sense for testing a server. How is the interface created? It
> seems like it would be possible for the mocked API to not match the actual
> API.

I agree. It's very easy for servers intending to mimic APIs and their behaviour 
to fall out of synchronization with the server they're attempting to mimic.

--  
Ian Cordasco
__
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] [stable] kilo and liberty is blocked on bug 1532048

[Ian Cordasco]

-Original Message-
From: Matt Riedemann 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: January 7, 2016 at 19:11:10
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  [openstack-dev] [stable] kilo and liberty is blocked on bug 1532048

> django_compressor 2.0 was released today which drops support for
> django<1.8 which is what stable/kilo g-r has django capped at, so
> horizon fails to install in kilo which breaks kilo jobs and grenade jobs
> in liberty.
>  
> The cap in stable/kilo g-r is here:
>  
> https://review.openstack.org/#/c/265025/
>  
> I'll babysit the reqs sync to horizon in kilo tonight which should then
> free things up again.

Thanks for babysitting those Matt! 

--  
Ian Cordasco
__
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] [Senlin]deletion policy for cross-zones/regions

[Yanyan Hu]

Thanks for starting this important job, Haiwei. Will leave comment on
etherpad.

2016-01-06 9:48 GMT+08:00 Haiwei Xu :

> Hi all,
>
> I wrote some use cases on etherpad to summarize the deletion policy for
> cross-zones/regions. Welcome to join the discussion.
>
> https://etherpad.openstack.org/p/deletion_policy_for_cross_zone_region
>
> Best regards,
> xuhaiwei
>
> __
> 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
>



-- 
Best regards,

Yanyan
__
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] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Tony Breeds]

On Tue, Jan 05, 2016 at 12:26:24PM +1300, Robert Collins wrote:
> On 5 January 2016 at 12:04, Robert Collins  wrote:
> ...
> > Indeed - 
> > https://bitbucket.org/pypa/setuptools/commits/fb35fcade302fa828d34e6aff952ec2398f2c877?at=get_command_list
> > - the failing bit AFAICT is indeed new code :/.
> 
> 
> Ok, so I've paged this all in. Here's whats up, and some thoughts on fixing 
> it.
> 
> Old pbr does indeed have a bug where 'setup.py test' will error with
> that unguarded import of what isn't meant to be a dependency.
> 
> The reason this started failing is that a bugfix to setuptools - so
> that the existing pbr code that wraps commands can wrap commands only
> added by setuptools plugins like 'wheel' was merged and included in a
> setuptools release.
> 
> This causes the pbr testr command to be loaded, which fails in old pbr.
> 
> The right answer is a back port of the import guard to pbr < 1.0.0 and
> a point release - 0.11.1.
> 
> IMO that is :)

I noticed:

http://logs.openstack.org/periodic-stable/periodic-horizon-python27-kilo/45f1797/tox/py27-2.log
so I went to do the back port and found it's already been done #winning!

Sachi King did it here:
 * https://review.openstack.org/#/c/263928/ which is ready to merge BUT it 
depends on
 * https://review.openstack.org/#/c/264010 which needs additional +2 +W's

It's be great if we could get a kilo (0.11.1) release to unblock 
periodic-horizon-python27-kilo

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] [senlin] Midcycle meetup (2016-01-11/12)

[Qiming Teng]

Thanks for your interests in this event. We will try our best to use the
etherpad and the IRC channel (#senlin) for guys who cannot participate
in person. Please feel free to raise questions during any discussion
sessions.

- Qiming

On Thu, Jan 07, 2016 at 10:20:12PM +0800, Zhipeng Huang wrote:
> do we have audio communication for the meetup ?
> 
> On Mon, Jan 4, 2016 at 4:41 PM, Ethan Lynn  wrote:
> 
> > Finally I get a chance to see you all!
> >
> > Best Regards,
> > Ethan Lynn
> >
> >
> >
> > On Dec 28, 2015, at 17:54, Yanyan Hu  wrote:
> >
> > Great! Can't wait to see you guys :)
> >
> > 2015-12-28 10:03 GMT+08:00 Qiming Teng :
> >
> >> Dear all,
> >>
> >> Wish you all a merry christmas and a happy new year.
> >>
> >> Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
> >> it goes beyond just a meetup between developers. We are inviting some
> >> users to share their real-life use cases and requirements.
> >>
> >> IBM Research China Lab will host the event. Please find the schedule
> >> etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle
> >>
> >> Any comments/suggestions are welcomed. We are looking forward to see you
> >> guys.
> >>
> >> Regards,
> >>   Qiming
> >>
> >>
> >> __
> >> 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
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > Yanyan
> > __
> > 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
> >
> >
> 
> 
> -- 
> Zhipeng (Howard) Huang
> 
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen


__
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] re-introducing twisted to global-requirements

[Ben Meyer]

On 01/07/2016 02:41 PM, Sean Dague wrote:
> On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:
>> Hi all,
>>
>> A change to global-requirements[1] introduces mimic, which is an http
>> server that can mock various APIs, including nova and ironic, including
>> control of error codes and timeouts. The ironic team plans to use this
>> for testing python-ironicclient without standing up a full ironic
>> environment.
>>
>> Here's the catch - mimic is built on twisted. I know twisted was
>> previously removed from OpenStack (or at least people said "pls no", I
>> don't know the full history). We didn't intend to stealth-introduce
>> twisted back into g-r, but it was pointed out to me that it may appear
>> this way, so here I am letting everyone know. lifeless pointed out that
>> when tests are failing, people may end up digging into mimic or twisted
>> code, which most people in this community aren't familiar with AFAIK,
>> which is a valid point though I hope it isn't required often.
>>
>> So, the primary question here is: do folks have a problem with adding
>> twisted here? We're holding off on Ironic changes that depend on this
>> until this discussion has happened, but aren't reverting the g-r change
>> until we decide one way or another.
>>
>> // jim
>>
>> [1] https://review.openstack.org/#/c/220268/
> What is the advantage of running another server like this over using
> requests-mock (which is used by other OpenStack projects for testing
> today)? The only difference here seems to be that you actually execute
> requests code in one case and not in the other.
>
> Requests-mock debugging when things go wrong seems a bit simpler.
>
> This is less about twisted and more about trying to not introduce yet
> another way to mock code in the tree that people need to understand.

As an outsider and lurker...this is a fair point. I also maintain
another project - StackInABox (and OpenStackInABox) - that resolves the
issue in a slightly different way that utilizes requests-mock to do
something similar, but closer to true unit tests.

The main advantage of mimic (https://pypi.python.org/pypi/mimic) is that
it can be independent of language framework (e.g you can use it for C++
or Java or Python2, Python3, or...) as its an independent process from
your testing, and the tasks can be handled very asynchronously so it can
mock out the responses for various tasks in a timely manner, and several
parts of a system can interact together during a test. You're also
utilizing a common mock of the entire system so multiple projects can
benefit from the same code base. It's kind of integration-test but not
quite - a good fit for projects where unit tests need multiple other
components working together, e.g services that use taskflow would
certainly benefit from using mimic.

The disadvantage of mimic from what I can tell is how the tests are
setup. But I'll leave that more to the mimic users and maintainers
(OpenStack Poppy, Rackspace Autoscale, etc) to explain.

For comparison: My StackInABox project provides a framework upon which
OpenStackInABox builds to provide a common model so multiple projects
benefit. I've used StackInABox on several of my own (non-OpenStack
projects) and my unit tests (run by tox) have been able to be nearly
complete integration tests. Aside from the slight use-case difference
(as exemplified by Rackspace AutoScale),  the main advantage of mimic
over my OpenStackInABox is the momentum behind it due to its use by
Rackspace AutoScale and OpenStack Poppy; I just don't have the resources
to build out the models in OpenStackInABox efficiently or quickly
(though I'd certainly welcome the help to do so). Advantage of the
StackInABox approach is every unit test is self-contained and you don't
have to change code to run the test in most cases (where you do, it's
minimal) - just like with using requests-mock; but you can't have two
services independently hit it - like with Rackspace AutoScale.

HTH,

Ben

P.S here's my two projects:
https://github.com/BenjamenMeyer/stackInABox ~
https://pypi.python.org/pypi/stackinabox
https://github.com/BenjamenMeyer/openstackinabox ~
https://pypi.python.org/pypi/openstackinabox

__
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] Testing concerns around boot from UEFI spec

[James Bottomley]

On Thu, 2016-01-07 at 18:03 +, Yuhong Bao wrote:
> James Bottomley  writes:
> > As you can see, they're mostly expired (in the US) but the last one
> > will expire in 2020 (if I calculate the date correctly).
> If you are referring to US6286013, 

That's the latest expiring one, yes.

> I read the patent and it looks like UEFI or for that matter any non
> -Windows implementation of FAT would probably not infringe on the
> patent.

Well, I'm not going to give you a legal opinion.  However, most people
think this patent covers the long vs short filenames conversions used
by vfat.  The UEFI implementation definitely implements the long vs
short name conversions for FAT/VFAT compatibility. 

James


__
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] re-introducing twisted to global-requirements

[Jay Pipes]

On 01/07/2016 03:01 PM, Jim Rollenhagen wrote:

On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:

On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:

Hi all,

A change to global-requirements[1] introduces mimic, which is an http
server that can mock various APIs, including nova and ironic, including
control of error codes and timeouts. The ironic team plans to use this
for testing python-ironicclient without standing up a full ironic
environment.

Here's the catch - mimic is built on twisted. I know twisted was
previously removed from OpenStack (or at least people said "pls no", I
don't know the full history). We didn't intend to stealth-introduce
twisted back into g-r, but it was pointed out to me that it may appear
this way, so here I am letting everyone know. lifeless pointed out that
when tests are failing, people may end up digging into mimic or twisted
code, which most people in this community aren't familiar with AFAIK,
which is a valid point though I hope it isn't required often.

So, the primary question here is: do folks have a problem with adding
twisted here? We're holding off on Ironic changes that depend on this
until this discussion has happened, but aren't reverting the g-r change
until we decide one way or another.

// jim

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


What is the advantage of running another server like this over using
requests-mock (which is used by other OpenStack projects for testing
today)? The only difference here seems to be that you actually execute
requests code in one case and not in the other.

Requests-mock debugging when things go wrong seems a bit simpler.

This is less about twisted and more about trying to not introduce yet
another way to mock code in the tree that people need to understand.

-Sean


We'd be using this for functional tests, not unit, where we can't really
inject mocks. The idea is that we could run a full functional suite
against either mimic or a full ironic environment, just by changing a
test setting.


I don't really see the point of a separate project like Mimic that has a 
whole bunch of reimplementations (mocked out) of all sorts of OpenStack 
(and RAX-specific) API services. It's just a great way to introduce a 
larger surface area for bugs to creep in -- since you have to keep the 
Mimic interfaces up to date with the real interfaces. Better to keep 
something like this -- if it is TRULY needed -- in-tree with the API 
service itself, so that the chances of divergence are reduced. This is 
similar to the fakevirt driver in Nova. It's in tree for good reason: 
when someone changes the virt driver interface, the fakevirt driver goes 
boom and needs to be changed in a corresponding fashion in the same patch.


What value does a functional test against an HTTP API service that does 
nothing (other than introduce greater surface area for bugs) actually 
offer over unit tests anyway?


-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] [puppet] Adding "IPv6" bracket handling utilities in openstacklib.

[Cody Herriges]

Sofer Athlan-Guyot wrote:
> Hi,
> 
> There are a few places where I would like to be able to check for IPv6
> address and add bracket to the parameters.  I think that would be a nice
> addition to the puppet-openstacklib/lib/puppet/parser.
> 
> Here the interface I have in mind with the puppet-nova module:
> 
> class nova::vncproxy::common (
>   $vncproxy_host = undef,
>   $vncproxy_protocol = undef,
>   $vncproxy_port = undef,
>   $vncproxy_path = undef,
> ) {
> 
>   include ::nova::deps
> 
>   $vncproxy_host_real = pick(
> ipv6_add_bracket_maybe($vncproxy_host,
>$::nova::compute::vncproxy_host,
>$::nova::vncproxy::host,
>false)
> 
> 
> This would returns an array with the host decorated with "[]" if the
> value is an IPv6 address.  Ideally the function could take only one
> value and return it or take an array and return an array for seamless
> integration in the code.
> 
> WDYT?
> 

I see this and it looks like that only only reason this is a problem is
because we've broken up all the pieces of data needed to generate a URI
so it becomes inappropriate to decorate the vncproxy_host variable's
value with "[]" because it lacks the port appended to the end.  What are
the ramifications of simply switching to a "$vnc_uri" variable much the
same that has happened with identity_uri and auth_uri, e.g.
https://review.openstack.org/262799. If one has to simply define the
entire URI, they'll be able to properly decorate the IPv6 address.

-- 
Cody



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] [puppet] Adding "IPv6" bracket handling utilities in openstacklib.

[Sofer Athlan-Guyot]

Emilien Macchi  writes:

> On 01/07/2016 01:07 PM, Sofer Athlan-Guyot wrote:
>> Hi,
>> 
>> There are a few places where I would like to be able to check for IPv6
>> address and add bracket to the parameters.  I think that would be a nice
>> addition to the puppet-openstacklib/lib/puppet/parser.
>> 
>> Here the interface I have in mind with the puppet-nova module:
>> 
>> class nova::vncproxy::common (
>>   $vncproxy_host = undef,
>>   $vncproxy_protocol = undef,
>>   $vncproxy_port = undef,
>>   $vncproxy_path = undef,
>> ) {
>> 
>>   include ::nova::deps
>> 
>>   $vncproxy_host_real = pick(
>> ipv6_add_bracket_maybe($vncproxy_host,
>>$::nova::compute::vncproxy_host,
>>$::nova::vncproxy::host,
>>false)
>> 
>> 
>> This would returns an array with the host decorated with "[]" if the
>> value is an IPv6 address.  Ideally the function could take only one
>> value and return it or take an array and return an array for seamless
>> integration in the code.
>> 
>> WDYT?
>> 
>
> The design looks okay to me, but on long term I would rather see the
> code in puppetlabs/stdlib rather than in our forge.

Well I can will make a proposal for such a patch afterward and will see
what happen.

> In short term, I agree to have this kind of code in openstacklib.

I have proposed such a patch there[0].

> Does it means we'll have to patch all our modules that contain host values?

As user/developer see fits.  The thing is that it is currently very hard
to do it, so people rely on external processes to adjust IPv6 with or
without bracket (like in packstack for instance).  If we give developer
a nice function that does it for them, then:
 - it can be integrated easily on new code;
 - old code can be easily patched when such problem appears.

So this can be a streamlined process, just reacting when bug appears and
try to ensure that new code handle the IPv6 case.

I have created this patch that use this feature there[1].  Comparing to
the proposed interface the difference is the splat operator[2] required
for the pick function.  All in all it should support whatever is thrown
at it, a bit like a filter.

[0] https://review.openstack.org/264927
[1] https://review.openstack.org/264951
[2] 
https://docs.puppetlabs.com/puppet/latest/reference/lang_expressions.html#splat

-- 
Sofer Athlan-Guyot

__
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] [trove] Adding support for HBase in Trove

[Peter MacKinnon]

On 1/6/16 8:20 PM, Amrith Kumar wrote:

Kevin Fox writes:


as far as that plugin ever should go. If you need scale up/down, etc, then
your starting to reimplement large swaths of Sahara, and like the Cinder
plugin for Nova, there could be a plugin that works identically to the stand
alone one that converts the same api over to a Sahara compatible one. You
then farm the work over to Sahara.

I believe that this is not the case. The entire framework for integration with 
Cinder, Nova etc., already exists in Trove.

Recall that trove already deals with about a dozen databases, several of which 
have support for clusters.

The code to add HBase support to trove doesn't have to implement all of this 
framework that already exists.

All that is being implemented is (literally) a Trove 'plugin' for HBase and a 
mechanism to build a HBase guest image.

-amrith


Right, I think that's the concern. A plugin for integration with a 
standalone/pseudo-distributed Hbase deployment has arguably a reasonable 
scale to be managed by a Trove guestagent. That agent would also fire up 
the client RPC services necessary for an end user to interact with Hbase 
remotely. But even the Hbase project views standalone mode as a 
devel/test capability only. The fully distributed model gets orders of 
magnitude more complex. Is the agent plugin just wiring into an existing 
multi-node Hbase deployment somewhere? Is it spawning/growing/shrinking 
HDFS endpoints itself?


The "we already have cluster support in Trove" argument doesn't really 
track in a production Hadoop space, IMHO. That's why Sahara was developed.


My $0.02,
\Pete




-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: Wednesday, January 06, 2016 7:32 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove

just my 2 cents... I think you can do both. The great thing about Trove is that
its providing an abstract api so users just deal with provisioning db's, scaling
db's, etc.

Having a simple plugin that doesn't depend on all of Sahara, for the case a
user only wants a single node HBase does make sense. Its much easier for an
Op to support that case if thats all their users ever want. But, thats probably
as far as that plugin ever should go. If you need scale up/down, etc, then
your starting to reimplement large swaths of Sahara, and like the Cinder
plugin for Nova, there could be a plugin that works identically to the stand
alone one that converts the same api over to a Sahara compatible one. You
then farm the work over to Sahara.

Then, its up to the ops to choose features and the overhead of supporting
Sahara, or not, and you don't have to support implementing a whole cluster
management system for Trove that already exists.

Thanks,
Kevin

From: Amrith Kumar [amr...@tesora.com]
Sent: Wednesday, January 06, 2016 3:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] Adding support for HBase in Trove

TL;DR Should Trove treat HBase as a special database because one use case is
as part of a large multi-node Hadoop cluster, and therefore either not
support it at all, or necessarily use Sahara to provision and manage a cluster?
There are pro's and con's and it is argued that the con's outweigh the pro's
and a blueprint/specification, and an implementation for basic Trove support
for HBase independent of Sahara has been submitted for review. See [3], [4]
and [5]. The benefits include the ability to provide the commonly used (in
development) standalone mode operation, and eliminate the dependency
on an additional OpenStack project thereby simplifying deployment.
Comments and feedback are welcome on the implementation, as well as the
specification and the approach.

The long version follows below.

The OpenStack Trove mission is to provide scalable and reliable Cloud
Database as a Service provisioning functionality for both relational and non-
relational database engines, and to continue to improve its fully-featured
and extensible open source framework [1].

An important aspect of the Trove value proposition is that it provides a
common control plane, a common API, and a common set of abstractions are
used to manage a number of different relational, and non-relational
database technologies. The common API contains primitives to create
database instances and clusters of a number of databases including MySQL
(MariaDB, Percona too), PostgreSQL, MongoDB, Cassandra, CouchDB,
Couchbase, IBM DB2, Vertica, and Redis.

Cluster support is also available for a number of databases including
MongoDB, Percona XtraDB cluster and Vertica, with more to come
imminently.

In effect, Trove is a framework for provisioning and managing the lifecycle of
a number of different database technologies; it provides only the control
plane. Users can do things like 

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

[Clayton O'Neill]

On Thu, Jan 7, 2016 at 10:44 AM, Mike Bayer  wrote:
> On 01/07/2016 07:39 AM, Clayton O'Neill wrote:
>> On Thu, Jan 7, 2016 at 2:49 AM, Roman Podoliaka  
>> wrote:
>>> In each child process eventlet WSGI server calls accept() in a loop to
>>> get a client socket from the kernel and then puts into a greenlet from
>>> a pool for processing:
>>
>> It’s worse than that.  What I’ve seen (via strace) is that eventlet actually
>> converts socket into a non-blocking socket, then converts that accept() into 
>> a
>> epoll()/accept() pair in every child.  Then when a connection comes in, every
>> child process wakes up out of poll and races to try to accept on the the
>> non-blocking socket, and all but one of them fails.
>
> is that eventlet-specific or would we see the same thing in gevent ?

I’m not sure.  For eventlet it’s a natural consequence of most of this being
implemented in Python.  It looks like some of this is implemented in C in
gevent, so they may handle the situation differently.

__
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] [trove] Adding support for HBase in Trove

[Amrith Kumar]

Michael, Pete, please see comments interspersed below.

>From the things that you and Pete (Peter MacKinnon) are saying, I don't 
>understand why there is an objection to accepting the currently proposed 
>implementation which is clearly for single node deployments? Both Standalone 
>and Pseudo-Distributed are by definition, explicitly, necessarily, absolutely, 
>positively, definitely single node. I can't be more explicit about that. 
>That's all that is being proposed at this time. See more comments below.

Further, the current proposal also chooses an implementation strategy that 
makes it much easier to handle fully-distributed in a different way in the 
future. Consider this, Trove could equally well have dealt with HBase using a 
single datastore for all operating modes. In the current implementation, one 
would create a HBase standalone instance using a command that included:

--datastore hbase-standalone 

And a pseudo-distributed instance by including

--datastore hbase-pseudo-distributed.

Trove could equally well function by having a single datastore (hbase) but this 
would make hbase-fully-distributed harder to do in a different way in the 
future. I consciously eschewed that path, for this very specific reason; it 
would limit choice in the future.

Now, the implementation behind hbase-fully-distributed could be a custom Trove 
guest agent that could (if we decided to go that route) interact with Sahara. 
However, an alternative implementation of hbase-fully-distributed could 
orchestrate everything natively in Trove. There is much flexibility in the 
current proposal, and I submit to you that this is being lost in your reading 
of the specification and the current implementation as proposed.

-amrith

> -Original Message-
> From: michael mccune [mailto:m...@redhat.com]
> Sent: Thursday, January 07, 2016 11:18 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> thanks for bringing this up Amrith,
> 
> On 01/06/2016 07:31 PM, Fox, Kevin M wrote:
> > Having a simple plugin that doesn't depend on all of Sahara, for the case a
> user only wants a single node HBase does make sense. Its much easier for an
> Op to support that case if thats all their users ever want. But, thats 
> probably
> as far as that plugin ever should go. If you need scale up/down, etc, then
> your starting to reimplement large swaths of Sahara, and like the Cinder
> plugin for Nova, there could be a plugin that works identically to the stand
> alone one that converts the same api over to a Sahara compatible one. You
> then farm the work over to Sahara.
> 
> i think this sounds reasonable, as long as we are limiting it to standalone
> mode. if the deployments start to take on a larger scope i agree it would be
> useful to leverage sahara for provisioning and scaling.

Why only standalone? The current proposal explicitly covers only standalone and 
pseudo-distributed which are both valid strictly (add other adjectives here to 
taste) single node topologies and the currently submitted specification 
specifically carves out fully-distributed operation as requiring further 
thought and contemplation. 

> 
> as the hbase installation grows beyond the standalone mode there will
> necessarily need to be hdfs and zookeeper support to allow for a proper
> production deployment. this also brings up questions of allowing the end-
> users to supply configurations for the hdfs and zookeeper processes, not to
> mention enabling support for high availability hdfs.

These are things that Trove already addresses, albeit in a different way than 
Sahara. Users can, as it turns out, specify configuration groups which can then 
be used to launch new instances, and can also be associated with groups of 
instances.
 
> 
> i can envision a scenario where trove could use sahara to provision and
> manage the clusters for hbase/hdfs/zk. this does pose some questions as
> we'd have to determine how the trove guest agent would be installed on the
> nodes, if there will need to be custom configurations used by trove, and if
> sahara will need to provide a plugin for bare (meaning no data processing
> framework) hbase/hdfs/zk clusters. but, i think these could be solved by
> either using custom images or a plugin in sahara that would install the
> necessary agents/configurations.

Let us not underestimate the effort for an end user to now deploy one more 
project. To a user already using Trove for a myriad of databases, requiring 
Sahara for supporting HBase Standalone sounds (to put it bluntly) a burden. 
Requiring it for Fully-Distributed mode may have some development benefits but 
it remains to be seen whether those benefits are really worth the contortions 
that Trove would have to go through. And in the Trove architecture, there is 
flexibility as described above to have multiple possible implementations for 
fully-distributed, one that would interface with 

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

[Dan Prince]

On Tue, 2015-12-22 at 15:36 +, Dougal Matthews wrote:
> Hi all,
> 
> This topic came up in the 2015-12-15 meeting[1], and again briefly
> today.
> After working with the code that came out of the deployment library
> spec[2] I
> had some concerns with how we are storing the templates.
> 
> Simply put, when we are dealing with 100+ files from tripleo-heat-
> templates
> how can we ensure consistency in Swift without any atomicity or
> transactions.
> I think this is best explained with a couple of examples.
> 
>  - When we create a new deployment plan (upload all the templates to
> swift)
>    how do we handle the case where there is an error? For example, if
> we are
>    uploading 10 files - what do we do if the 5th one fails for some
> reason?
>    There is a patch to do a manual rollback[3], but I have concerns
> about
>    doing this in Python. If Swift is completely inaccessible for a
> short
>    period the rollback wont work either.

Would Swift's Bulk middleware help us here:

https://github.com/openstack/swift/blob/master/swift/common/middleware/
bulk.py

We don't currently have that middleware enabled but we certainly could
try it out. NOTE the "Expand tar files into a swift account" feature...

Dan

> 
>  - When deploying to Heat, we need to download all the YAML files
> from Swift.
>    This can take a couple of seconds. What happens if somebody starts
> to
>    upload a new version of the plan in the middle? We could end up
> trying to
>    deploy half old and half new files. We wouldn't have a consistent
> view of
>    the database.
> 
> We had a few suggestions in the meeting:
> 
>  - Add a locking mechanism. I would be concerned about deadlocks or
> having to
>    lock for the full duration of a deploy.
>  - Store the files in a tarball (so we only deal with one file). I
> think we
>    could still hit issues with multiple operations unless we
> guarantee that
>    only one instance of the API is ever running.
> 
> I think these could potentially be made to work, but at this point
> are we
> using the best tool for the job?
> 
> For alternatives, I see a can think of a couple of options:
> 
> - Use a database, like we did for Tuskar and most OpenStack API's do.
> - Invest time in building something on Swift.
> - Glance was transitioning to be a Artifact store. I don't know the
> status of
>   this or if it would meet out needs.
> 
> Any input, ideas or suggestions would be great!
> 
> Thanks,
> Dougal
> 
> 
> [1]: http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.201
> 5-12-15-14.03.log.html#l-89
> [2]: https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka
> /tripleo-overcloud-deployment-library.html
> [3]: https://review.openstack.org/#/c/257481/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] Monasca -agent

[Chandeep Khamba]

HI ,

I have some nodes which are Centos 6.5 and am trying to run the monasca-agent 
via the monasca-setup script.

I am able to run the script but it does not work it out

/usr/share/monasca/bin/monasca-setup -u xx -p xxx --project_name admin 
-s monitoring --keystone_url xxx --monasca_url x 
--config_dir /etc/monasca/agent --log_dir /var/log/monasca/agent —-overwrite

INFO: Enabled monasca-agent service via SysV init script

INFO: Configuring base Agent settings.

INFO: Configuring System

INFO: Configured network

INFO: Configured disk

INFO: Configured load

INFO: Configured memory

INFO: Configured cpu

INFO: Configuring Ntp

INFO: Enabling the ntp plugin

INFO: Postfix found but the required sudo access is not configured.

Refer to plugin documentation for more detail

INFO: Starting monasca-agent service via SysV init script

Stopping Monasca Monitoring Agent (stopping supervisord) monasca-agent

Starting Monasca Monitoring Agent (using supervisord) monasca-agent

ERROR: The service did not startup correctly see /var/log/monasca/agent



 While If I do a manual run of the collector and forwarder they seem to work 
pretty well for me

The same stuff works on a centos 7 machine pretty well .

Is there something else I can use to daemonize my agent instead of supervisord  
 ?  Or am I missing something  ?

PS  : monasca-agent version : 1.1.15

Thanks
Chandeep Khamba



__
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] re-introducing twisted to global-requirements

[Jim Rollenhagen]

On Thu, Jan 07, 2016 at 02:41:12PM -0500, Sean Dague wrote:
> On 01/07/2016 02:09 PM, Jim Rollenhagen wrote:
> > Hi all,
> > 
> > A change to global-requirements[1] introduces mimic, which is an http
> > server that can mock various APIs, including nova and ironic, including
> > control of error codes and timeouts. The ironic team plans to use this
> > for testing python-ironicclient without standing up a full ironic
> > environment.
> > 
> > Here's the catch - mimic is built on twisted. I know twisted was
> > previously removed from OpenStack (or at least people said "pls no", I
> > don't know the full history). We didn't intend to stealth-introduce
> > twisted back into g-r, but it was pointed out to me that it may appear
> > this way, so here I am letting everyone know. lifeless pointed out that
> > when tests are failing, people may end up digging into mimic or twisted
> > code, which most people in this community aren't familiar with AFAIK,
> > which is a valid point though I hope it isn't required often.
> > 
> > So, the primary question here is: do folks have a problem with adding
> > twisted here? We're holding off on Ironic changes that depend on this
> > until this discussion has happened, but aren't reverting the g-r change
> > until we decide one way or another.
> > 
> > // jim
> > 
> > [1] https://review.openstack.org/#/c/220268/
> 
> What is the advantage of running another server like this over using
> requests-mock (which is used by other OpenStack projects for testing
> today)? The only difference here seems to be that you actually execute
> requests code in one case and not in the other.
> 
> Requests-mock debugging when things go wrong seems a bit simpler.
> 
> This is less about twisted and more about trying to not introduce yet
> another way to mock code in the tree that people need to understand.
> 
>   -Sean

We'd be using this for functional tests, not unit, where we can't really
inject mocks. The idea is that we could run a full functional suite
against either mimic or a full ironic environment, just by changing a
test setting.

// 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

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

[Jay Faulkner]

It's also worth noting that the mimic team, along with other Rackers who work 
on Twistd, all worked to get python 3 support for mimic and associated 
dependencies in order to get this into OpenStack. I think it's safe to say this 
is a very friendly upstream and will help resolve any issues we might suss out.


Thanks,

Jay Faulkner


From: Dmitry Tantsur 
Sent: Thursday, January 7, 2016 11:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] re-introducing twisted to global-requirements

2016-01-07 20:09 GMT+01:00 Jim Rollenhagen 
>:
Hi all,

A change to global-requirements[1] introduces mimic, which is an http
server that can mock various APIs, including nova and ironic, including
control of error codes and timeouts. The ironic team plans to use this
for testing python-ironicclient without standing up a full ironic
environment.

Here's the catch - mimic is built on twisted. I know twisted was
previously removed from OpenStack (or at least people said "pls no", I
don't know the full history). We didn't intend to stealth-introduce
twisted back into g-r, but it was pointed out to me that it may appear
this way, so here I am letting everyone know. lifeless pointed out that
when tests are failing, people may end up digging into mimic or twisted
code, which most people in this community aren't familiar with AFAIK,
which is a valid point though I hope it isn't required often.

Btw, I've spent some amount of time (5 years?) with twisted on my previous 
jobs. While my memory is no longer fresh on it, I can definitely be pinged to 
help with it, if problems appear.


So, the primary question here is: do folks have a problem with adding
twisted here? We're holding off on Ironic changes that depend on this
until this discussion has happened, but aren't reverting the g-r change
until we decide one way or another.

// jim

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

__
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



--
--
-- Dmitry Tantsur
--
__
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] Adding Ubuntu Liberty to Kolla-Mitaka

[Thomas Goirand]

On 01/07/2016 10:08 PM, Jeremy Stanley wrote:
> This is the bit of detail I was missing... so one of the jobs you
> want runs Tempest against an OpenStack installation consisting of
> modified distibution packages.

This is what I've been doing for about a year in my own Jenkins server,
with quite reasonably good result (there's only an issue with the Glance
image rights which I couldn't figure out, leading to 27 failures against
1100 passed tests: see [1]). So yes indeed! :)

> Noble, if somewhat ambitious.

Well, it's all figured-out already...

> Jobs to
> just test that your package configuration builds on a clean system
> and passes checks with lintian, piuparts, et cetera would be a much
> simpler place to start.

Sure, but I'm well passed that stage. I'd run that, but not only, as
experienced showed me that it's easy to break the whole setup with
packages that otherwise can perfectly build and get installed. For
example, I noticed very late in the Liberty cycle that Glance and Cinder
had broken configuration generation (due to upstream issues). With such
tempest tests, it'd be figured out as soon as it breaks, and that's the
goal here.

> Cool, let's continue the discussion in that and subsequent code
> reviews. It'll hopefully be a much more productive exchange that
> way.

Thanks for your review. Hopefully, I'll learn about upstream infra by
doing it. I'm just afraid to eat even more of your time by attempting to
do write the patches myself... :/

Cheers,

Thomas Goirand (zigo)

[1]
https://liberty-jessie.pkgs.mirantis.com/job/openstack-tempest-ci/40/console


__
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] Is Swift a good choice of database for the TripleO API?

[Fox, Kevin M]

I don't think the radosgw supports bulk yet. They haven't for a very long time. 
:/

Thanks,
Kevin

From: Dan Prince [dpri...@redhat.com]
Sent: Thursday, January 07, 2016 9:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] Is Swift a good choice of database for 
the TripleO API?

On Tue, 2015-12-22 at 15:36 +, Dougal Matthews wrote:
> Hi all,
>
> This topic came up in the 2015-12-15 meeting[1], and again briefly
> today.
> After working with the code that came out of the deployment library
> spec[2] I
> had some concerns with how we are storing the templates.
>
> Simply put, when we are dealing with 100+ files from tripleo-heat-
> templates
> how can we ensure consistency in Swift without any atomicity or
> transactions.
> I think this is best explained with a couple of examples.
>
>  - When we create a new deployment plan (upload all the templates to
> swift)
>how do we handle the case where there is an error? For example, if
> we are
>uploading 10 files - what do we do if the 5th one fails for some
> reason?
>There is a patch to do a manual rollback[3], but I have concerns
> about
>doing this in Python. If Swift is completely inaccessible for a
> short
>period the rollback wont work either.

Would Swift's Bulk middleware help us here:

https://github.com/openstack/swift/blob/master/swift/common/middleware/
bulk.py

We don't currently have that middleware enabled but we certainly could
try it out. NOTE the "Expand tar files into a swift account" feature...

Dan

>
>  - When deploying to Heat, we need to download all the YAML files
> from Swift.
>This can take a couple of seconds. What happens if somebody starts
> to
>upload a new version of the plan in the middle? We could end up
> trying to
>deploy half old and half new files. We wouldn't have a consistent
> view of
>the database.
>
> We had a few suggestions in the meeting:
>
>  - Add a locking mechanism. I would be concerned about deadlocks or
> having to
>lock for the full duration of a deploy.
>  - Store the files in a tarball (so we only deal with one file). I
> think we
>could still hit issues with multiple operations unless we
> guarantee that
>only one instance of the API is ever running.
>
> I think these could potentially be made to work, but at this point
> are we
> using the best tool for the job?
>
> For alternatives, I see a can think of a couple of options:
>
> - Use a database, like we did for Tuskar and most OpenStack API's do.
> - Invest time in building something on Swift.
> - Glance was transitioning to be a Artifact store. I don't know the
> status of
>   this or if it would meet out needs.
>
> Any input, ideas or suggestions would be great!
>
> Thanks,
> Dougal
>
>
> [1]: http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.201
> 5-12-15-14.03.log.html#l-89
> [2]: https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka
> /tripleo-overcloud-deployment-library.html
> [3]: https://review.openstack.org/#/c/257481/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [Ironic] Heads up for devstack IRONIC_QEMU_HOOK_PATH variable change

[Lucas Alvares Gomes]

Hi,

Hi this email is just a heads up to alert people that the
"IRONIC_QEMU_HOOK_PATH" variable for DevStack is not available
anymore, a path [0] was merged and replaced that variable with another
one called "IRONIC_LIBVIRT_HOOKS_PATH" without deprecating it first.

For context, the "IRONIC_QEMU_HOOK_PATH" was introduced as part of the
patch [1] few days before Christmas, so it was relatively new.

[0] https://review.openstack.org/#/c/264164/
[1] https://review.openstack.org/#/c/257987/

Cheers,
Lucas

__
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] [trove] Adding support for HBase in Trove

[Greg Hill]

I don't work on Sahara, but I do work on a similar closed-source project.
FWIW, I agree with Kevin here.  standalone and pseudo-distributed HBase
are only intended for Hbase developers to test code without having to spin
up a cluster; it's not meant for operators or users to actually use as a
database. Hbase is designed to run on HDFS and relies on Zookeeper for
coordination as well. Unless trove is going to re-implement half of
Sahara, having it there makes no sense, and will ultimately only lead to
confusion among users who see Hbase and think they're getting something
useful when they are in fact not.

My $0.02

Greg

On 1/7/16, 12:19 PM, "Fox, Kevin M"  wrote:

>Oh. And I'd suggest having this conversation with the Sahara team. They
>may have some interesting insight into the issue.
>
>Thanks,
>Kevin
>
>From: Fox, Kevin M
>Sent: Thursday, January 07, 2016 9:44 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
>
>the whole hadoopish stack is unusual though. I suspect users often want
>to slice and dice all the components that run together on the cluster,
>where HBase is just one component of the shared cluster. I can totally
>envision users walking up to my door saying, I provisioned this HBase
>system with Trove, and now I want to run such and such job on the
>cluster... Building on top of Sahara enables that kind of thing. If trove
>wants to do the clustering all itself, then that's either out of the
>picture, or you end up having to add lots of sahara like functionality in
>the end to get its functionality back up to where users will want it.
>
>Thanks,
>Kevin
>
>From: michael mccune [m...@redhat.com]
>Sent: Thursday, January 07, 2016 8:17 AM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
>
>thanks for bringing this up Amrith,
>
>On 01/06/2016 07:31 PM, Fox, Kevin M wrote:
>> Having a simple plugin that doesn't depend on all of Sahara, for the
>>case a user only wants a single node HBase does make sense. Its much
>>easier for an Op to support that case if thats all their users ever
>>want. But, thats probably as far as that plugin ever should go. If you
>>need scale up/down, etc, then your starting to reimplement large swaths
>>of Sahara, and like the Cinder plugin for Nova, there could be a plugin
>>that works identically to the stand alone one that converts the same api
>>over to a Sahara compatible one. You then farm the work over to Sahara.
>
>i think this sounds reasonable, as long as we are limiting it to
>standalone mode. if the deployments start to take on a larger scope i
>agree it would be useful to leverage sahara for provisioning and scaling.
>
>as the hbase installation grows beyond the standalone mode there will
>necessarily need to be hdfs and zookeeper support to allow for a proper
>production deployment. this also brings up questions of allowing the
>end-users to supply configurations for the hdfs and zookeeper processes,
>not to mention enabling support for high availability hdfs.
>
>i can envision a scenario where trove could use sahara to provision and
>manage the clusters for hbase/hdfs/zk. this does pose some questions as
>we'd have to determine how the trove guest agent would be installed on
>the nodes, if there will need to be custom configurations used by trove,
>and if sahara will need to provide a plugin for bare (meaning no data
>processing framework) hbase/hdfs/zk clusters. but, i think these could
>be solved by either using custom images or a plugin in sahara that would
>install the necessary agents/configurations.
>
>of course, this does add a layer of complexity as operators who wish
>this type of deployment will need to have both trove and sahara, but imo
>this would be easier than replicating the work that sahara has done with
>these technologies.
>
>regards,
>mike
>
>__
>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 

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

[Dmitry Tantsur]

2016-01-07 20:09 GMT+01:00 Jim Rollenhagen :

> Hi all,
>
> A change to global-requirements[1] introduces mimic, which is an http
> server that can mock various APIs, including nova and ironic, including
> control of error codes and timeouts. The ironic team plans to use this
> for testing python-ironicclient without standing up a full ironic
> environment.
>
> Here's the catch - mimic is built on twisted. I know twisted was
> previously removed from OpenStack (or at least people said "pls no", I
> don't know the full history). We didn't intend to stealth-introduce
> twisted back into g-r, but it was pointed out to me that it may appear
> this way, so here I am letting everyone know. lifeless pointed out that
> when tests are failing, people may end up digging into mimic or twisted
> code, which most people in this community aren't familiar with AFAIK,
> which is a valid point though I hope it isn't required often.
>

Btw, I've spent some amount of time (5 years?) with twisted on my previous
jobs. While my memory is no longer fresh on it, I can definitely be pinged
to help with it, if problems appear.


>
> So, the primary question here is: do folks have a problem with adding
> twisted here? We're holding off on Ironic changes that depend on this
> until this discussion has happened, but aren't reverting the g-r change
> until we decide one way or another.
>
> // jim
>
> [1] https://review.openstack.org/#/c/220268/
>
> __
> 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
>



-- 
--
-- Dmitry Tantsur
--
__
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] Testing concerns around boot from UEFI spec

[Yuhong Bao]

James Bottomley  writes:
> As you can see, they're mostly expired (in the US) but the last one
> will expire in 2020 (if I calculate the date correctly).
If you are referring to US6286013, I read the patent and it looks like 
UEFI or for that matter any non-Windows implementation of FAT would 
probably not infringe on the patent. 


__
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] [trove] Adding support for HBase in Trove

[Fox, Kevin M]

Oh. And I'd suggest having this conversation with the Sahara team. They may 
have some interesting insight into the issue.

Thanks,
Kevin

From: Fox, Kevin M
Sent: Thursday, January 07, 2016 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove

the whole hadoopish stack is unusual though. I suspect users often want to 
slice and dice all the components that run together on the cluster, where HBase 
is just one component of the shared cluster. I can totally envision users 
walking up to my door saying, I provisioned this HBase system with Trove, and 
now I want to run such and such job on the cluster... Building on top of Sahara 
enables that kind of thing. If trove wants to do the clustering all itself, 
then that's either out of the picture, or you end up having to add lots of 
sahara like functionality in the end to get its functionality back up to where 
users will want it.

Thanks,
Kevin

From: michael mccune [m...@redhat.com]
Sent: Thursday, January 07, 2016 8:17 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove

thanks for bringing this up Amrith,

On 01/06/2016 07:31 PM, Fox, Kevin M wrote:
> Having a simple plugin that doesn't depend on all of Sahara, for the case a 
> user only wants a single node HBase does make sense. Its much easier for an 
> Op to support that case if thats all their users ever want. But, thats 
> probably as far as that plugin ever should go. If you need scale up/down, 
> etc, then your starting to reimplement large swaths of Sahara, and like the 
> Cinder plugin for Nova, there could be a plugin that works identically to the 
> stand alone one that converts the same api over to a Sahara compatible one. 
> You then farm the work over to Sahara.

i think this sounds reasonable, as long as we are limiting it to
standalone mode. if the deployments start to take on a larger scope i
agree it would be useful to leverage sahara for provisioning and scaling.

as the hbase installation grows beyond the standalone mode there will
necessarily need to be hdfs and zookeeper support to allow for a proper
production deployment. this also brings up questions of allowing the
end-users to supply configurations for the hdfs and zookeeper processes,
not to mention enabling support for high availability hdfs.

i can envision a scenario where trove could use sahara to provision and
manage the clusters for hbase/hdfs/zk. this does pose some questions as
we'd have to determine how the trove guest agent would be installed on
the nodes, if there will need to be custom configurations used by trove,
and if sahara will need to provide a plugin for bare (meaning no data
processing framework) hbase/hdfs/zk clusters. but, i think these could
be solved by either using custom images or a plugin in sahara that would
install the necessary agents/configurations.

of course, this does add a layer of complexity as operators who wish
this type of deployment will need to have both trove and sahara, but imo
this would be easier than replicating the work that sahara has done with
these technologies.

regards,
mike

__
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] [all] re-introducing twisted to global-requirements

[Jim Rollenhagen]

Hi all,

A change to global-requirements[1] introduces mimic, which is an http
server that can mock various APIs, including nova and ironic, including
control of error codes and timeouts. The ironic team plans to use this
for testing python-ironicclient without standing up a full ironic
environment.

Here's the catch - mimic is built on twisted. I know twisted was
previously removed from OpenStack (or at least people said "pls no", I
don't know the full history). We didn't intend to stealth-introduce
twisted back into g-r, but it was pointed out to me that it may appear
this way, so here I am letting everyone know. lifeless pointed out that
when tests are failing, people may end up digging into mimic or twisted
code, which most people in this community aren't familiar with AFAIK,
which is a valid point though I hope it isn't required often.

So, the primary question here is: do folks have a problem with adding
twisted here? We're holding off on Ironic changes that depend on this
until this discussion has happened, but aren't reverting the g-r change
until we decide one way or another.

// jim

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

__
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] Adding "IPv6" bracket handling utilities in openstacklib.

[Emilien Macchi]

On 01/07/2016 01:07 PM, Sofer Athlan-Guyot wrote:
> Hi,
> 
> There are a few places where I would like to be able to check for IPv6
> address and add bracket to the parameters.  I think that would be a nice
> addition to the puppet-openstacklib/lib/puppet/parser.
> 
> Here the interface I have in mind with the puppet-nova module:
> 
> class nova::vncproxy::common (
>   $vncproxy_host = undef,
>   $vncproxy_protocol = undef,
>   $vncproxy_port = undef,
>   $vncproxy_path = undef,
> ) {
> 
>   include ::nova::deps
> 
>   $vncproxy_host_real = pick(
> ipv6_add_bracket_maybe($vncproxy_host,
>$::nova::compute::vncproxy_host,
>$::nova::vncproxy::host,
>false)
> 
> 
> This would returns an array with the host decorated with "[]" if the
> value is an IPv6 address.  Ideally the function could take only one
> value and return it or take an array and return an array for seamless
> integration in the code.
> 
> WDYT?
> 

The design looks okay to me, but on long term I would rather see the
code in puppetlabs/stdlib rather than in our forge.
In short term, I agree to have this kind of code in openstacklib.
Does it means we'll have to patch all our modules that contain host values?
-- 
Emilien Macchi



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] [puppet] Adding "IPv6" bracket handling utilities in openstacklib.

[Sofer Athlan-Guyot]

Hi,

There are a few places where I would like to be able to check for IPv6
address and add bracket to the parameters.  I think that would be a nice
addition to the puppet-openstacklib/lib/puppet/parser.

Here the interface I have in mind with the puppet-nova module:

class nova::vncproxy::common (
  $vncproxy_host = undef,
  $vncproxy_protocol = undef,
  $vncproxy_port = undef,
  $vncproxy_path = undef,
) {

  include ::nova::deps

  $vncproxy_host_real = pick(
ipv6_add_bracket_maybe($vncproxy_host,
   $::nova::compute::vncproxy_host,
   $::nova::vncproxy::host,
   false)


This would returns an array with the host decorated with "[]" if the
value is an IPv6 address.  Ideally the function could take only one
value and return it or take an array and return an array for seamless
integration in the code.

WDYT?

-- 
Sofer Athlan-Guyot

__
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] [telemetry][aodh][vitrage] The purpose of notification about alarm updating

[AFEK, Ifat (Ifat)]

> -Original Message-
> From: gord chung [mailto:g...@live.ca]
> Sent: Wednesday, January 06, 2016 3:52 PM
> 
> On 06/01/2016 8:11 AM, AFEK, Ifat (Ifat) wrote:
> > Hi,
> >
> > We would like to be notified once an alarm state is changed, so we
> prefer using the message bus.
> > As far as I understand, ceilometer and aodh APIs do not provide
> immediate notifications. If we use the APIs, we will have to poll the
> data periodically and look for changes, and we will get them in delay.
> By listening to the message bus we can get the notifications
> immediately, like we do with other openstack components.
> >
> > Is there an advantage in using the API instead?
> > And what do you mean by "aggregation on events data"? what kind of
> aggregations can we do?
> >
> >
> is the idea that you don't want to use a webhook to be notified? when
> an alarm is computed by aodh-evaluator, it sends this alarm (via
> message
> queue) to aodh-notifier which in turns does the webhook. if you just
> disable aodh-notifier, the alarm won't be consumed and you can listen
> to it yourself.

We have two motivations: one is that we want to get notifications on every 
change, but we don't want to register our webhook to each and every alarm; and 
the other is that we already listen to the message bus for other openstack 
components, so we would like to handle aodh the same way.

If we disable aodh-notifier, won't it have other impacts on the system? What if 
someone else used a webhook, and won't be notified because we disabled the 
notifier?

> alternatively, it was discussed that maybe adding a zaqar notifier
> would be useful. that way, aodh-notifier would send alarm to zaqar and
> you could configure it to requeue or maybe send a smtp.

What are the advantages of using Zaqar over using the message bus? Is the 
solution you suggested already supported? 

Thanks,
Ifat.



__
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] Proposal for new metrics-threshold-filter

[SURO]

Hi all,

I have proposed a nova-spec[1] for a new scheduling filter based on 
metrics thresholds. This is slightly different than weighted metrics 
filter. The rationale and use-case is explained in detail in the spec[1].


The implementation is also ready for review[2]. The effort is tracked 
with a blueprint[3].


I request the community to review them and provide valuable feedback.


[1] - https://review.openstack.org/#/c/257596/
[2] - https://review.openstack.org/#/c/254423/
[3] - 
https://blueprints.launchpad.net/nova/+spec/metrics-threshold-filter





__
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] re-introducing twisted to global-requirements

[Davanum Srinivas]

A bit more information. the dependency for twisted is not in
global-requirements.txt, it will be only added to
upper-constraints.txt when the CI job/bot proposes it next.

Thanks,
Dims

On Thu, Jan 7, 2016 at 2:09 PM, Jim Rollenhagen  wrote:
> Hi all,
>
> A change to global-requirements[1] introduces mimic, which is an http
> server that can mock various APIs, including nova and ironic, including
> control of error codes and timeouts. The ironic team plans to use this
> for testing python-ironicclient without standing up a full ironic
> environment.
>
> Here's the catch - mimic is built on twisted. I know twisted was
> previously removed from OpenStack (or at least people said "pls no", I
> don't know the full history). We didn't intend to stealth-introduce
> twisted back into g-r, but it was pointed out to me that it may appear
> this way, so here I am letting everyone know. lifeless pointed out that
> when tests are failing, people may end up digging into mimic or twisted
> code, which most people in this community aren't familiar with AFAIK,
> which is a valid point though I hope it isn't required often.
>
> So, the primary question here is: do folks have a problem with adding
> twisted here? We're holding off on Ironic changes that depend on this
> until this discussion has happened, but aren't reverting the g-r change
> until we decide one way or another.
>
> // jim
>
> [1] https://review.openstack.org/#/c/220268/
>
> __
> 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] [trove] Adding support for HBase in Trove

[Amrith Kumar]

> -Original Message-
> From: michael mccune [mailto:m...@redhat.com]
> Sent: Thursday, January 07, 2016 3:12 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> On 01/07/2016 11:59 AM, Amrith Kumar wrote:
> >  From the things that you and Pete (Peter MacKinnon) are saying, I don't
> understand why there is an objection to accepting the currently proposed
> implementation which is clearly for single node deployments? Both
> Standalone and Pseudo-Distributed are by definition, explicitly, necessarily,
> absolutely, positively, definitely single node. I can't be more explicit about
> that. That's all that is being proposed at this time. See more comments
> below.
> 
> i didn't think i explicitly objected to the spec, if it seems that way then i
> apologize. after reading the spec and the comments, it seemed that there
> was some question about engagement with the sahara team. i wanted to
> help bring some light to the issues surrounding deploying hbase and thought
> it would be good to participate in the discussion.

You are correct Michael. There was a suggestion that we should engage with the 
Sahara team (in the Trove team meeting yesterday) and that is what prompted 
this email thread. So I appreciate your participation as one who is a member of 
the Sahara team.

> 
> > Further, the current proposal also chooses an implementation strategy that
> makes it much easier to handle fully-distributed in a different way in the
> future. Consider this, Trove could equally well have dealt with HBase using a
> single datastore for all operating modes. In the current implementation, one
> would create a HBase standalone instance using a command that included:
> >
> > --datastore hbase-standalone
> >
> > And a pseudo-distributed instance by including
> >
> > --datastore hbase-pseudo-distributed.
> >
> 
> and this delineation sounds reasonable to me
> 
> > Trove could equally well function by having a single datastore (hbase) but
> this would make hbase-fully-distributed harder to do in a different way in the
> future. I consciously eschewed that path, for this very specific reason; it
> would limit choice in the future.
> 
> agreed
> 
> > Now, the implementation behind hbase-fully-distributed could be a
> custom Trove guest agent that could (if we decided to go that route) interact
> with Sahara. However, an alternative implementation of hbase-fully-
> distributed could orchestrate everything natively in Trove. There is much
> flexibility in the current proposal, and I submit to you that this is being 
> lost in
> your reading of the specification and the current implementation as
> proposed.
> 
> i don't think your characterization of my reading comprehension is fair.
> as i stated earlier, i wanted to participate in the discussion surrounding
> deploying a technology that sahara currently deploys. fwiw, i agree with what
> you are saying here, but i also think it is axiomatic, the trove team can 
> choose
> whichever path it would like for implementation.
> 
> >> i think this sounds reasonable, as long as we are limiting it to
> >> standalone mode. if the deployments start to take on a larger scope i
> >> agree it would be useful to leverage sahara for provisioning and scaling.
> >
> > Why only standalone? The current proposal explicitly covers only
> standalone and pseudo-distributed which are both valid strictly (add other
> adjectives here to taste) single node topologies and the currently submitted
> specification specifically carves out fully-distributed operation as requiring
> further thought and contemplation.
> 
> i think starting with standalone mode (and not pseudo-distributed) is a more
> conservative approach to this. my reason for suggesting limiting this to
> standalone is that even in pseudo-distributed mode the need for managing
> hdfs and zookeeper are present, i wanted to highlight some of of the overlap
> and the issues that will start to creep in surrounding this deployment.
> 

The current code (submitted for review) provides both standalone and 
pseudo-distributed support. You will observe that the standalone and 
pseudo-distributed implementations do install zookeeper. As you are no doubt 
aware, one of the recommended ways to force the HBase Master server to always 
bind to a well-known port in favor of the ephemeral ports is to stipulate  
hbase.cluster.distributed is True (see 
https://review.openstack.org/#/c/262048/5/scripts/files/elements/ubuntu-hbase-standalone/install.d/20-install-hbase
 line 121). So, as it turns out, the code to deploy hdfs and zookeeper is 
already part of the proposed implementation.


> >> as the hbase installation grows beyond the standalone mode there will
> >> necessarily need to be hdfs and zookeeper support to allow for a
> >> proper production deployment. this also brings up questions of
> >> allowing the end- users to supply configurations for the hdfs and
> >> zookeeper 

[openstack-dev] [nova][ec2-api] Removing Nova's In tree ec2 API code in favor of ec2-api project

[Davanum Srinivas]

Dear Nova cores,

Sorry this did not make into the Nova weekly meeting agenda yesterday.

Is it time for dropping the EC2/ObjectStore REST API Since we've told
folks since Kilo that we will be removing this code and we dropped the
entries api-paste.ini in Liberty?
https://review.openstack.org/#/c/263368/

Thanks,
Dims


-- 
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] IPv6 in OSP-7 - need your help

[Emilien Macchi]

On 01/07/2016 04:26 PM, Emilien Macchi wrote:
> I would like to initiate some investigation to estimate the work to do
> if we want to backport IPv6 to OSP-7.
> 
> If you've been working on IPv6 a lot or even a little and you know the
> work that has been done, please look:
> https://trello.com/c/fTCr7Tg2/90-ipv6-in-osp7-notag
> 
> ... and contribute if you have some thoughts.
> (if you don't have permissions please ping me or anyone on #rhos-mgt)
> 
> Thanks a lot,
> 

Apologize for the noise, I wanted to use another mailing-list (facepalm).
-- 
Emilien Macchi



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] [nova][libvirt] Deprecating the live_migration_flag and block_migration_flag config options

[Mark McLoughlin]

On Thu, 2016-01-07 at 12:23 +0100, Sahid Orentino Ferdjaoui wrote:
> On Mon, Jan 04, 2016 at 09:12:06PM +, Mark McLoughlin wrote:
> > Hi
> > 
> > commit 8ecf93e[1] got me thinking - the live_migration_flag config
> > option unnecessarily allows operators choose arbitrary behavior of the
> > migrateToURI() libvirt call, to the extent that we allow the operator
> > to configure a behavior that can result in data loss[1].
> > 
> > I see that danpb recently said something similar:
> > 
> >   https://review.openstack.org/171098
> > 
> >   "Honestly, I wish we'd just kill off  'live_migration_flag' and
> >   'block_migration_flag' as config options. We really should not be
> >   exposing low level libvirt API flags as admin tunable settings.
> > 
> >   Nova should really be in charge of picking the correct set of flags
> >   for the current libvirt version, and the operation it needs to
> >   perform. We might need to add other more sensible config options in
> >   their place [..]"
> 
> Nova should really handle internal flags and this serie is running in
> the right way.
> 
> > ...
> 
> >   4) Add a new config option for tunneled versus native:
> > 
> >    [libvirt]
> >    live_migration_tunneled = true
> > 
> >  This enables the use of the VIR_MIGRATE_TUNNELLED flag. We have 
> >      historically defaulted to tunneled mode because it requires the 
> >      least configuration and is currently the only way to have a 
> >      secure migration channel.
> > 
> >      danpb's quote above continues with:
> > 
> >        "perhaps a "live_migration_secure_channel" to indicate that 
> >         migration must use encryption, which would imply use of 
> >         TUNNELLED flag"
> > 
> >      So we need to discuss whether the config option should express the
> >      choice of tunneled vs native, or whether it should express another
> >      choice which implies tunneled vs native.
> > 
> >        https://review.openstack.org/263434
> 
> We probably have to consider that operator does not know much about
> internal libvirt flags, so options we are exposing for him should
> reflect benefice of using them. I commented on your review we should
> at least explain benefice of using this option whatever the name is.

As predicted, plenty of discussion on this point in the review :)

You're right that we don't give the operator any guidance in the help
message about how to choose true or false for this:

  Whether to use tunneled migration, where migration data is 
  transported over the libvirtd connection. If True,
  we use the VIR_MIGRATE_TUNNELLED migration flag

libvirt's own docs on this are here:

  https://libvirt.org/migration.html#transport

which emphasizes:

  - the data copies involved in tunneling
  - the extra configuration steps required for native
  - the encryption support you get when tunneling

The discussions I've seen on this topic wrt Nova have revolved around:

  - that tunneling allows for an encrypted transport[1]
  - that qemu's NBD based drive-mirror block migration isn't supported
    using tunneled mode, and that danpb is working on fixing this
    limitation in libvirt
  - "selective" block migration[2] won't work with the fallback qemu
    block migration support, and so won't currently work in tunneled
    mode

So, the advise to operators would be:

  - You may want to choose tunneled=False for improved block migration 
    capabilities, but this limitation will go away in future.
  - You may want to choose tunneled=False if you wish to trade and
    encrypted transport for a (potentially negligible) performance
    improvement.

Does that make sense?

As for how to name the option, and as I said in the review, I think it
makes sense to be straightforward here and make it clearly about
choosing to disable libvirt's tunneled transport.

If we name it any other way, I think our explanation for operators will
immediately jump to explaining (a) that it influences the TUNNELLED
flag, and (b) the differences between the tunneled and native
transports. So, if we're going to have to talk about tunneled versus
native, why obscure that detail?

But, Pawel strongly disagrees.

One last point I'd make is this isn't about adding a *new*
configuration capability for operators. As we deprecate and remove
these configuration options, we need to be careful not to remove a
capability that operators are currently depending on for arguably
reasonable reasons.

[1] - https://review.openstack.org/#/c/171098/
[2] - https://review.openstack.org/#/c/227278


> >   5) Add a new config option for additional migration flags:
> > 
> >    [libvirt]
> >    live_migration_extra_flags = VIR_MIGRATE_COMPRESSED
> > 
> >  This allows operators to continue to experiment with libvirt behaviors
> >  in safe ways without each use case having to be accounted for.
> > 
> >    https://review.openstack.org/263435
> > 
> >  We would disallow setting the following flags via this option:
> > 
> > 

Re: [openstack-dev] [heat] Client checking of server version

[Ryan Brown]

On 01/06/2016 12:05 PM, Zane Bitter wrote:

On 05/01/16 16:37, Steven Hardy wrote:

On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote:

I ran into an issue in a review about moving environment resolution from
client to server [1]. It revolves around clients being able to access
older
versions of servers (that's a pretty simplistic description; see [2]
for the
spec).

Before the holiday, Steve Hardy and I were talking about the
complications
involved. In my case, there's no good way to differentiate an older
server
from a legitimate error.

Since the API isn't versioned to the extent that we can leverage that
value,
I was looking into using the template versions call. Something along the
lines of:

   supported_versions = hc.template_versions.list()
   version_nums = [i.to_dict()['version'].split('.')[1] for i in
supported_versions]
   mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of
generalized
utility method in the client, under the assumption that we'll need
this sort
of check in the future for the same backward compatibility requirements.

So a few questions:

1. Does anyone strongly disagree to checking supported template
versions as
a way of determining the specifics of the server API.


Ok, so some valid concerns have been raised over deriving things using
the
HOT version (although I do still wonder if the environment itself
should be
versioned, just like the templates, then we could rev the environment
verion and say it supports a list, vs changing anything in the API, but
that's probably a separate discussion).

Taking a step back for a moment, the original discussion was around
providing transparent access to the new interface via heatclient, but
that
isn't actually a hard requirement - the old interface works fine for many
users, so we could just introduce a new interface (which would eventually
become the default, after all non-EOL heat versions released support the
new API argument):

Currently we do:

heat stack-create foo -f foo.yaml -e a.yaml -e b.yaml

And this implies some client-side resolution of the multiple -e
arguments.

-e is short for "--environment-file", but we could introduce a new
format,
e.g "-E", short for "--environment-files":


I agree with Zane, this looks like a usability (and backwards compat) 
nightmare.


Not only do you have to get over everyone's muscle memory of typing `-e` 
(I've got it bad) but also all the scripts folks have that use heatclient.


Then there's the docs between "If ... blah blah ... then use -E, 
otherwise use -e" will be a pretty fat stumbling block for folks that 
use different deploys of OpenStack (say, a Juno prod cloud and a Kilo 
staging cloud) if they want to use heat templates on both.



heat stack-create foo -f foo.yaml -E a.yaml -E b.yaml

This option would work the same way as the current interface, but it
would
pass the files unmodified for resolution inside heat (by using the new
API
format), and as it's opt-in, it's leaving all the current heatclient
interfaces alone without any internal fallback logic?


That would certainly work, but it sounds like a usability/support
nightmare :(

Is there a reason we wouldn't consider bumping the API version to 1.1
for this? We'll have to figure out how to do it some time.

cheers,
Zane.

__
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


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, 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

[openstack-dev] IPv6 in OSP-7 - need your help

[Emilien Macchi]

I would like to initiate some investigation to estimate the work to do
if we want to backport IPv6 to OSP-7.

If you've been working on IPv6 a lot or even a little and you know the
work that has been done, please look:
https://trello.com/c/fTCr7Tg2/90-ipv6-in-osp7-notag

... and contribute if you have some thoughts.
(if you don't have permissions please ping me or anyone on #rhos-mgt)

Thanks a lot,
-- 
Emilien Macchi



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] [app-catalog] App Catalog IRC meeting minutes - 1/7/2016

[Christopher Aedo]

We had a good meeting this morning, and mainly focused on resolving
the work around checking for dead links in the Community App Catalog.
This will also include updating the hash for any entry that includes a
"hash_url".

As soon as this work lands and is in the period pipeline to run daily,
I'll send a note with more details.  In the mean time, the related
commits are here:
https://review.openstack.org/#/c/260198/
https://review.openstack.org/#/c/264523/
https://review.openstack.org/#/c/264978/

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:30 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2016/app_catalog.2016-01-07-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:43)
  * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog
(docaedo, 17:04:07)
* Resolve direction and plans for dead-link checking  (docaedo,
  17:06:56)
  * LINK:
https://blueprints.launchpad.net/app-catalog/+spec/detect-stale-entries
(docaedo, 17:07:00)
  * LINK: https://etherpad.openstack.org/p/app-catalog-hash-update
(docaedo, 17:16:02)
* Open discussion  (docaedo, 17:34:08)

Meeting ended at 17:39:03 UTC.

People present (lines said)
---
* docaedo (49)
* kfox (40)
* openstack (3)
* j_king (1)

Generated by `MeetBot`_ 0.1.4

__
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