date:20150109

[openstack-dev] Request Spec Freeze Exception For More Image Properties Support

2015-01-09 Thread Jiang, Yunhong

Hello Nova Community,
Please grant a freeze exception for the nova spec "more image 
properties support" at https://review.openstack.org/#/c/138937/ . 

The potential changes in nova are limited, affecting only to the 
corresponding scheduler filters. Its purpose is to ensure and enforce image 
provider hints/recommendations, something the image provider knows best, to 
achieve optimal performance and/or meet compliance or other constraints. 

Thanks

__
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][neutron]VIF_VHOSTUSER

2015-01-09 Thread Ian Wells

Once more, I'd like to revisit the VIF_VHOSTUSER discussion [1].  I still
think this is worth getting into Nova's libvirt driver - specifically
because there's actually no way to distribute this as an extension; since
we removed the plugin mechanism for VIF drivers, it absolutely requires a
code change in the libvirt driver.  This means that there's no graceful way
of distributing an aftermarket VHOSTUSER driver for libvirt.

The standing counterargument to adding it is that nothing in the upstream
or 3rd party CI would currently test the VIF_VHOSTUSER code.  I'm not sure
that's a showstopper, given the code is zero risk to anyone when it's not
being used, and clearly is going to be experimental when it's enabled.  So,
Nova cores, would it be possible to incorporate this without a
corresponding driver in base Neutron?

Cheers,
-- 
Ian.

[1] https://review.openstack.org/#/c/96140/
__
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] [Heat] Convergence proof-of-concept showdown

2015-01-09 Thread Clint Byrum

Excerpts from Zane Bitter's message of 2015-01-09 14:57:21 -0800:
> On 08/01/15 05:39, Anant Patil wrote:
> > 1. The stack was failing when there were single disjoint resources or
> > just one resource in template. The graph did not include this resource
> > due to a minor bug in dependency_names(). I have added a test case and
> > fix here:
> > https://github.com/anantpatil/heat-convergence-prototype/commit/b58abd77cf596475ecf3f19ed38adf8ad3bb6b3b
> 
> Thanks, sorry about that! I will push a patch to fix it up.
> 
> > 2. The resource graph is created with keys in both forward order
> > traversal and reverse order traversal and the update will finish the
> > forward order and attempt the reverse order. If this is the case, then
> > the update-replaced resources will be deleted before the update is
> > complete and if the update fails, the old resource is not available for
> > roll-back; a new resource has to be created then. I have added a test
> > case at the above mentioned location.
> >
> > In our PoC, the updates (concurrent updates) won't remove a
> > update-replaced resource until all the resources are updated, and
> > resource clean-up phase is started.
> 
> Hmmm, this is a really interesting question actually. That's certainly 
> not how Heat works at the moment; we've always assumed that rollback is 
> "best-effort" at recovering the exact resources you had before. It would 
> be great to have users weigh in on how they expect this to behave. I'm 
> curious now what CloudFormation does.
> 
> I'm reluctant to change it though because I'm pretty sure this is 
> definitely *not* how you would want e.g. a rolling update of an 
> autoscaling group to happen.
> 
> > It is unacceptable to remove the old
> > resource to be rolled-back to since it may have changes which the user
> > doesn't want to loose;
> 
> If they didn't want to lose it they shouldn't have tried an update that 
> would replace it. If an update causes a replacement or an interruption 
> to service then I consider the same fair game for the rollback - the 
> user has already given us permission for that kind of change. (Whether 
> the user's consent was informed is a separate question, addressed by 
> Ryan's update-preview work.)
> 

In the original vision we had for using scaled groups to manage, say,
nova-compute nodes, you definitely can't "create" new servers, so you
can't just create all the new instances without de-allocating some.

That said, thats why we are using in-place methods like rebuild.

I think it would be acceptable to have cleanup run asynchronously,
and to have rollback re-create anything that has already been cleaned up.

__
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] [devstack] noVNC disabled by default?

2015-01-09 Thread Sean Dague

On 01/09/2015 06:12 PM, Solly Ross wrote:
> Hi,   
>   
> I just noticed that noVNC was disabled by default in devstack (the relevant   
>   
> change was
>   
> https://review.openstack.org/#/c/140860/).
>   
>   
>   
> Now, if I understand correctly (based on the short commit message), the   
>   
> rationale is that we don't want devstack to reply on non-OpenStack Git
>   
> repos, so that devstack doesn't fail when some external Git hosting   
>   
> service (e.g. GitHub) goes down.

Realistically the policy is more about the fact that we should be using
released (and commonly available) versions of dependent software.
Ideally from packages, but definitely not from git trees. We don't want
to be testing everyone else's bleeding edge, there are lots of edges and
pointy parts in OpenStack as it is.

>   
>   
> This is all fine and dandy (and a decent idea, IMO), but this leaves devstack 
>   
> installing a "broken" installation of Horizon by default -- Horizon still 
>  
> attempts to show the noVNC console when you go to the "console" tab for an
>   
> instance, which is a bit confusing, initially.  Now, it wasn't particularly   
>   
> hard to track not particularly hard to track down *why* this happened (hmm... 
>   
> my stackrc seems to be missing "n-novnc" in ENABLED_SERVICES.  Go-go-gadget   
>   
> `git blame`), but it strikes me as a bit inconsistent and inconvenient.   
>   
>   
>   
> Personally, I would like to see noVNC back as a default service, since it 
>   
> can be useful when trying to see what your VM is actually doing during
>   
> boot, or if you're having network issues.  Is there anything I can do 
>   
> as a noVNC maintainer to help?
>   
>   
>   
> We (the noVNC team) do publish releases, and I've been trying to make 
>   
> sure that they happen in a more timely fashion.  In the past, it was 
> necessary  
> to use Git master to ensure that you got the latest version (there was a  
>   
> 2-year gap between 0.4 and 0.5!), but I'm trying to change that.  Currently,  
>   
> it would appear that most of the distros are still using the old version 
> (0.4), 
> but versions 0.5 and 0.5.1 are up on GitHub as release tarballs (0.5 being a 
> 3  
> months old and 0.5.1 having been tagged a couple weeks ago).  I will attempt 
> to 
> work with distro maintainers to get the packages updated.  However, in the 
> mean 
> time, is there a place would be acceptable to place the releases so that 
> devstack
> can install them?

If you rewrite the noNVC installation in devstack to work from a release
URL that includes the released version on it, I think that would be
sufficient to turn it back on. Again, ideally this should be in distros,
but I think we could work on doing release installs until then,
especially if the install process is crisp.

I am looking at the upstream release tarball right now though, and don't
see and INSTALL instructions in it. So lets see what the devstack patch
would look like to do the install.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [devstack] noVNC disabled by default?

2015-01-09 Thread Solly Ross

Hi, 
I just noticed that noVNC was disabled by default in devstack (the relevant 
change was  
https://review.openstack.org/#/c/140860/).  

Now, if I understand correctly (based on the short commit message), the 
rationale is that we don't want devstack to reply on non-OpenStack Git  
repos, so that devstack doesn't fail when some external Git hosting 
service (e.g. GitHub) goes down.

This is all fine and dandy (and a decent idea, IMO), but this leaves devstack   
installing a "broken" installation of Horizon by default -- Horizon still  
attempts to show the noVNC console when you go to the "console" tab for an  
instance, which is a bit confusing, initially.  Now, it wasn't particularly 
hard to track not particularly hard to track down *why* this happened (hmm...   
my stackrc seems to be missing "n-novnc" in ENABLED_SERVICES.  Go-go-gadget 
`git blame`), but it strikes me as a bit inconsistent and inconvenient. 

Personally, I would like to see noVNC back as a default service, since it   
can be useful when trying to see what your VM is actually doing during  
boot, or if you're having network issues.  Is there anything I can do   
as a noVNC maintainer to help?  

We (the noVNC team) do publish releases, and I've been trying to make   
sure that they happen in a more timely fashion.  In the past, it was necessary  
to use Git master to ensure that you got the latest version (there was a
2-year gap between 0.4 and 0.5!), but I'm trying to change that.  Currently,
it would appear that most of the distros are still using the old version (0.4), 
but versions 0.5 and 0.5.1 are up on GitHub as release tarballs (0.5 being a 3  
months old and 0.5.1 having been tagged a couple weeks ago).  I will attempt to 
work with distro maintainers to get the packages updated.  However, in the mean 
time, is there a place would be acceptable to place the releases so that 
devstack
can install them?   

Best Regards,   
Solly Ross 

__
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] [Keystone][tc] Removal Plans for keystoneclient.middleware.auth_token

2015-01-09 Thread Sean Dague

On 01/09/2015 01:59 AM, Morgan Fainberg wrote:
> That was a copy paste error. The response was meant to be:
> 
> Yes, that is the issue, unbounded version on the stable branches. 

So if that is the root issue, there are other fixes. Our current policy
of keeping clients uncapped on stable branches is due to trying to do a
few too many things at once in the test environment.

Some history:

There are basically no explicit live tests for clients libraries / cli
at all. It remains a hole. As a project we've fallen back to secondary
testing of those clients through the fact that OpenStack services
implicitly use them to talk to each other (and they used to be inside a
small amount of tempest code, but that's been removed).

As a policy we expect:

CLI/LIBS to work with both newer and older clouds. Which totally makes
sense. Especially when you think about the use case like nodepool where
you have 1 process that talks to 2 clouds at different levels of
OpenStack at the same time.

Barring any real testing of the CLI/LIBS we do the "install latest libs
in stable/juno stacks" as a fall back.

But... what that actually creates is a stable/icehouse env with the
latest client code being used to talk between components (i.e. from nova
-> cinder). Which I am sure is how basically zero people in the world
have their clouds. You don't go randomly upping libraries in these
environments unless you have to. It also actually allows backports to
require newer library features which wouldn't exist there.

So... we could (and probably should) cap libraries on stable branches.
There are definitely a few dragons there, at least one of which Doug
discovered in that you can't really do this for only a slice of the
libraries, as if any are allowed to roll forward they can stick you in
conflicting requirements land. We know they all worked at a revision set
when we released, we need to capture that and move on.

This would allow the keystone team to drop having to carry that dead code.

Clearly we also need to actually have the clients test themselves
against OpenStack explicitly, not just by accident. But that's a bigger
challenge to overcome.

-Sean

> 
> --Morgan
> 
> Sent via mobile
> 
>> On Jan 8, 2015, at 22:57, Morgan Fainberg  wrote:
>>
>>
>>
 On Jan 8, 2015, at 16:10, Sean Dague  wrote:

> On 01/08/2015 07:01 PM, Morgan Fainberg wrote:
>
> On Jan 8, 2015, at 3:56 PM, Sean Dague  wrote:
>
> On 01/08/2015 06:29 PM, Morgan Fainberg wrote:
>> As of Juno all projects are using the new keystonemiddleware package for 
>> auth_token middleware. Recently we’ve been running into issues with 
>> maintenance of the now frozen (and deprecated) 
>> keystoneclient.middleware.auth_token code. Ideally all deployments 
>> should move over to the new package. In some cases this may or may not 
>> be as feasible due to requirement changes when using the new middleware 
>> package on particularly old deployments (Grizzly, Havana, etc).
>>
>> The Keystone team is looking for the best way to support our deployer 
>> community. In a perfect world we would be able to convert icehouse 
>> deployments to the new middleware package and instruct deployers to use 
>> either an older keystoneclient or convert to keystonemiddleware if they 
>> want the newest keystoneclient lib (regardless of their deployment 
>> release). For releases older than Icehouse (EOLd) there is no way to 
>> communicate in the repositories/tags a change to require 
>> keystonemiddleware.
>>
>> There are 2 viable options to get to where we only have one version of 
>> the keystonemiddleware to maintain (which for a number of reasons, 
>> primarily relating to security concerns is important).
>>
>> 1) Work to update Icehouse to include the keystonemiddleware package for 
>> the next stable release. Sometime after this stable release remove the 
>> auth_token (and other middlewares) from keystoneclient. The biggest 
>> downside is this adds new dependencies in an old release, which is poor 
>> for packaging and deployers (making sure paste-ini is updated etc).
>>
>> 2) Plan to remove auth_token from keystoneclient once icehouse hits EOL. 
>> This is a better experience for our deployer base, but does not solve 
>> the issues around solid testing with the auth_token middleware from 
>> keystoneclient (except for the stable-icehouse devstack-gate jobs).
>>
>> I am looking for insight, preferences, and other options from the 
>> community and the TC. I will propose this topic for the next TC meeting 
>> so that we can have a clear view on how to handle this in the most 
>> appropriate way that imparts the best balance between maintainability, 
>> security, and experience for the OpenStack providers, deployers, and 
>> users.
>
> So, ignoring the code a bit for a second, what are the interfa

Re: [openstack-dev] [Heat] Convergence proof-of-concept showdown

2015-01-09 Thread Zane Bitter

On 08/01/15 05:39, Anant Patil wrote:

1. The stack was failing when there were single disjoint resources or
just one resource in template. The graph did not include this resource
due to a minor bug in dependency_names(). I have added a test case and
fix here:
https://github.com/anantpatil/heat-convergence-prototype/commit/b58abd77cf596475ecf3f19ed38adf8ad3bb6b3b

Thanks, sorry about that! I will push a patch to fix it up.

2. The resource graph is created with keys in both forward order
traversal and reverse order traversal and the update will finish the
forward order and attempt the reverse order. If this is the case, then
the update-replaced resources will be deleted before the update is
complete and if the update fails, the old resource is not available for
roll-back; a new resource has to be created then. I have added a test
case at the above mentioned location.

In our PoC, the updates (concurrent updates) won't remove a
update-replaced resource until all the resources are updated, and
resource clean-up phase is started.

Hmmm, this is a really interesting question actually. That's certainly
not how Heat works at the moment; we've always assumed that rollback is
"best-effort" at recovering the exact resources you had before. It would
be great to have users weigh in on how they expect this to behave. I'm
curious now what CloudFormation does.

I'm reluctant to change it though because I'm pretty sure this is
definitely *not* how you would want e.g. a rolling update of an
autoscaling group to happen.

It is unacceptable to remove the old
resource to be rolled-back to since it may have changes which the user
doesn't want to loose;

If they didn't want to lose it they shouldn't have tried an update that
would replace it. If an update causes a replacement or an interruption
to service then I consider the same fair game for the rollback - the
user has already given us permission for that kind of change. (Whether
the user's consent was informed is a separate question, addressed by
Ryan's update-preview work.)

and that's why probably they use the roll-back
flag.

I don't think there's any basis for saying that. People use the rollback
flag because they want the stack left in a consistent state even if an
error occurs.

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

79 matches

Mail list logo