openstack-nova defaults in Fedora 17

[Mark McLoughlin]

Hey,

For OpenStack Essex in Fedora 17, I thought it was worth discussing:

  1) Should we switch to the new --config-file format by default? I
     think we discussed this briefly before and decided we would. We
     should probably go ahead to have it settled in before the test day.

  2) I see we've added support for force_dhcp_release=True; should we 
     make it the default?

  3) 'root_helper=sudo nova-rootwrap' is the default now, right? All 
     the test cases still work fine? No user impact?

  4) 'rpc_backend=nova.rpc.impl_qpid' is also the default now? I think 
      we had some debate about whether we should require any of the 
      messaging libs by default? Did we come to a conclusion? My 
      instinct it to require the default lib only

Thanks!
Mark.

[Pádraig Brady]

On 02/20/2012 03:51 PM, Mark McLoughlin wrote:
>  Hey,
>  
>  For OpenStack Essex in Fedora 17, I thought it was worth discussing:
>  
>    1) Should we switch to the new --config-file format by default? I
>       think we discussed this briefly before and decided we would. We
>       should probably go ahead to have it settled in before the test day. 
I think it makes sense to do this ASAP.
I tried and had some issues with it.
Are there specific commits I could cherry pick,
or will I wait for essex-4 which is supposed
to land on March 1st, 7 days before the test day.

>    2) I see we've added support for force_dhcp_release=True;
> should we 
>       make it the default? 
I'm not sure of the implications. It seems dafe enough.
If the option is just to cater for systems without `dhcp_release`
then it's fairly redundant, as the availability of that could be
checked for at startup. Not that it would be the first redundant
option ever created :)  I'll ask on the openstack list.

>    3) 'root_helper=sudo nova-rootwrap' is the default now,
> right? All 
>       the test cases still work fine? No user impact? 
I ran through most of the test day cases with no issue.

>    4) 'rpc_backend=nova.rpc.impl_qpid' is also the default
> now? I think 
>        we had some debate about whether we should require any of the 
>        messaging libs by default? Did we come to a conclusion? My 
>        instinct it to require the default lib only 
I discussed that with Russell who implemented the Qpid support,
and he made the point that you might not even want to run the
qpid broker on the same host as the nova services.
I intentionally didn't depend on an amqp server for now.

cheers,
Pádraig.

[Russell Bryant]

On 02/20/2012 11:30 AM, Pádraig Brady wrote:
>  On 02/20/2012 03:51 PM, Mark McLoughlin wrote:
> > Hey,
> >
> > For OpenStack Essex in Fedora 17, I thought it was worth discussing:
> >
> >   1) Should we switch to the new --config-file format by default? I
> >      think we discussed this briefly before and decided we would. We
> >      should probably go ahead to have it settled in before the test day.
>  
>  I think it makes sense to do this ASAP. 
Agreed.

>  I tried and had some issues with it.
>  Are there specific commits I could cherry pick,
>  or will I wait for essex-4 which is supposed
>  to land on March 1st, 7 days before the test day.
>  
> >   2) I see we've added support for force_dhcp_release=True; should we 
> >      make it the default?
>  
>  I'm not sure of the implications. It seems dafe enough.
>  If the option is just to cater for systems without `dhcp_release`
>  then it's fairly redundant, as the availability of that could be
>  checked for at startup. Not that it would be the first redundant
>  option ever created :)  I'll ask on the openstack list.
>  
> >   3) 'root_helper=sudo nova-rootwrap' is the default now, right? All 
> >      the test cases still work fine? No user impact?
>  
>  I ran through most of the test day cases with no issue.
>  
> >   4) 'rpc_backend=nova.rpc.impl_qpid' is also the default now? I think 
> >       we had some debate about whether we should require any of the 
> >       messaging libs by default? Did we come to a conclusion? My 
> >       instinct it to require the default lib only
>  
>  I discussed that with Russell who implemented the Qpid support,
>  and he made the point that you might not even want to run the
>  qpid broker on the same host as the nova services.
>  I intentionally didn't depend on an amqp server for now. 
Right, I don't think it makes sense to depend on qpid-cpp-server or
rabbitmq-server at all.  I think Mark was referring to the dependencies
on the client libs: python-qpid, python-kombu, python-carrot.  Depending
on only python-qpid out of those is fine with me.  We should document
how to switch back to rabbitmq/kombu, though since there are so many
docs out there referring to that configuration.

-- 
Russell Bryant

[Mark McLoughlin]

On Mon, 2012-02-20 at 16:30 +0000, Pádraig Brady wrote:
>  On 02/20/2012 03:51 PM, Mark McLoughlin wrote:
>  > Hey,
>  > 
>  > For OpenStack Essex in Fedora 17, I thought it was worth discussing:
>  > 
>  >   1) Should we switch to the new --config-file format by default? I
>  >      think we discussed this briefly before and decided we would. We
>  >      should probably go ahead to have it settled in before the test day.
>  
>  I think it makes sense to do this ASAP.
>  I tried and had some issues with it.
>  Are there specific commits I could cherry pick,
>  or will I wait for essex-4 which is supposed
>  to land on March 1st, 7 days before the test day. 
You should be able to use --config-file with essex-3; if there are
specific problems, let me know and I can figure something out

Good point on the timing with essex-4 being unfortunate, but if we start
packaging release candidate tarballs (from milestone-proposed), we
should be able to have essex-4 available and working for the test day.

i.e. essex-4 is a full week before the test day and I'd expect tarballs
from milestone-proposed to be available this week or early next week.

Cheers,
Mark.

[Mark McLoughlin]

On Mon, 2012-02-20 at 12:04 -0500, Russell Bryant wrote:
>  On 02/20/2012 11:30 AM, Pádraig Brady wrote:
>  > On 02/20/2012 03:51 PM, Mark McLoughlin wrote:
>  >>   4) 'rpc_backend=nova.rpc.impl_qpid' is also the default now? I think 
>  >>       we had some debate about whether we should require any of the 
>  >>       messaging libs by default? Did we come to a conclusion? My 
>  >>       instinct it to require the default lib only
>  > 
>  > I discussed that with Russell who implemented the Qpid support,
>  > and he made the point that you might not even want to run the
>  > qpid broker on the same host as the nova services.
>  > I intentionally didn't depend on an amqp server for now.
>  
>  Right, I don't think it makes sense to depend on qpid-cpp-server or
>  rabbitmq-server at all.  I think Mark was referring to the dependencies
>  on the client libs: python-qpid, python-kombu, python-carrot.  Depending
>  on only python-qpid out of those is fine with me. 
Cool, that makes sense. I'd actually forgotten about the distinction
between the libs and the server.

>  We should document how to switch back to rabbitmq/kombu, though
> since
>  there are so many docs out there referring to that configuration. 
Yep.

Cheers,
Mark.

[Pádraig Brady]

On 02/20/2012 05:04 PM, Russell Bryant wrote:
>  Right, I don't think it makes sense to depend on qpid-cpp-server
> or
>  rabbitmq-server at all.  I think Mark was referring to the dependencies
>  on the client libs: python-qpid, python-kombu, python-carrot.  Depending
>  on only python-qpid out of those is fine with me.  We should document
>  how to switch back to rabbitmq/kombu, though since there are so many
>  docs out there referring to that configuration. 
I left the dependencies on all those, as they're minimal
(and have minimal dependencies themselves).

Requires:         python-qpid
Requires:         python-carrot
Requires:         python-kombu
Requires:         python-amqplib

cheers,
Pádraig.

[Russell Bryant]

On 02/20/2012 01:12 PM, Pádraig Brady wrote:
>  On 02/20/2012 05:04 PM, Russell Bryant wrote:
> > Right, I don't think it makes sense to depend on qpid-cpp-server or
> > rabbitmq-server at all.  I think Mark was referring to the dependencies
> > on the client libs: python-qpid, python-kombu, python-carrot.  Depending
> > on only python-qpid out of those is fine with me.  We should document
> > how to switch back to rabbitmq/kombu, though since there are so many
> > docs out there referring to that configuration.
>  
>  I left the dependencies on all those, as they're minimal
>  (and have minimal dependencies themselves).
>  
>  Requires:         python-qpid
>  Requires:         python-carrot
>  Requires:         python-kombu
>  Requires:         python-amqplib 
That's true, they are pretty small ... that's fine with me.

-- 
Russell Bryant

[Mark McLoughlin]

Hey,

Looks like we'll need a default value set for firewall_driver now:

  https://bugs.launchpad.net/nova/+bug/924266

Cheers,
Mark.

[Pádraig Brady]

On 02/21/2012 07:04 AM, Mark McLoughlin wrote:
>  Hey,
>  
>  Looks like we'll need a default value set for firewall_driver now:
>  
>    https://bugs.launchpad.net/nova/+bug/924266 
Well spotted. We'll need this for the next essex milestone inclusion,
so I'll add it now.

thanks,
Pádraig.