Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Jim Baker]

On Wed, May 25, 2016 at 12:47 PM, Tim Bell  wrote:

> Slight concern on how to deploy on a RHEL system base as software
> collections are non-trivial.
>

But also worth keeping in mind, Craton and its dependencies (most
significantly, MySQL or PostgreSQL, + Taskflow dependencies, including
ZooKeeper for operators at scale) will only be deployed on nodes that are
actually running Craton specifically, not at all on the fleet itself.


>
>
> If we can keep the client to be still python 2.X compatible, that would be
> a significant help.
>

Very good point about differentiating the (forthcoming) Python client from
the rest of the Craton codebase.

Like other projects, and as would be expected, the Python client
(python-craton) is just going to be a wrapper of Craton's REST API. We will
write it such that it is compatible for Python 2.7 and 3.4+; and tested
accordingly. I guess we were thinking this implicitly - but now stated
explicitly.


>
>
> Getting good development productivity/deployments should probably outweigh
> these concerns though…
>

I appreciate that. Python 2.7 is technical debt at this point; sometimes we
have to support it if it makes sense (the client), but given that we have
to support Python 3 as well, moving forward on that with a new project
means less work/more productivity.

- JIm
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Jim Baker]

We will want to move the main repo to OpenStack infra, with the usual
mirror to github.com/openstack/craton. I don't think we need to worry about
mirroring to github.com/rackerlabs/craton as well. A simple reference there
pointing to the new location should suffice.

Basically I'm just trying to keep disruption to the dev team to
zero/minimum.


On Wed, May 25, 2016 at 1:31 PM, sean roberts 
wrote:

> True, we will want to wait if we want decide to move or copy the
> rackerlabs/craton repo. I can create the project patch and then pin it so
> it doesn't get merged.
>
> On Wed, May 25, 2016 at 10:27 AM, Jim Baker  wrote:
>
>> Sean, thanks for your help here, it's very much appreciated!
>>
>> The move then should be straightforward once we get past our first
>> milestone, on or around June 10; but any prep in advance sounds good.
>>
>>
>>
>> On Wed, May 25, 2016 at 12:37 PM, sean roberts 
>> wrote:
>>
>>> Now that we have settled on the name, setting up the project
>>> infrastructure is straightforward. I have done this a few times and am
>>> ready to do it for craton.
>>>
>>> On Tue, May 24, 2016 at 3:51 PM, Jim Baker  wrote:
>>>
 On Tue, May 24, 2016 at 6:36 PM, Sam Morrison 
 wrote:

> I’m in favour of using 3.5. We are in the process of moving things to
> ubuntu xenial and 3.5 is native there.
>

 Thanks for the feedback!


>
> BTW when is Craton planning on getting into openstack gerrit etc?
>

 The specific timeline of the move to gerrit is not something we have
 actively discussed, because of the usual: we are trying to complete our
 phase 1 milestone. Currently we are projecting June 10 (based on Monte
 Carlo modeling), but this could slip. In any event, once we finish
 milestone 1, moving to OpenStack Gerrit and infrastructure in general ASAP
 would make sense.

 In other words, it should be quite soon!

 - Jim

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


>>>
>>>
>>> --
>>>
>>> ~ sean
>>>
>>
>>
>
>
> --
>
> ~ sean
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Jim Baker]

Sean, thanks for your help here, it's very much appreciated!

The move then should be straightforward once we get past our first
milestone, on or around June 10; but any prep in advance sounds good.



On Wed, May 25, 2016 at 12:37 PM, sean roberts 
wrote:

> Now that we have settled on the name, setting up the project
> infrastructure is straightforward. I have done this a few times and am
> ready to do it for craton.
>
> On Tue, May 24, 2016 at 3:51 PM, Jim Baker  wrote:
>
>> On Tue, May 24, 2016 at 6:36 PM, Sam Morrison  wrote:
>>
>>> I’m in favour of using 3.5. We are in the process of moving things to
>>> ubuntu xenial and 3.5 is native there.
>>>
>>
>> Thanks for the feedback!
>>
>>
>>>
>>> BTW when is Craton planning on getting into openstack gerrit etc?
>>>
>>
>> The specific timeline of the move to gerrit is not something we have
>> actively discussed, because of the usual: we are trying to complete our
>> phase 1 milestone. Currently we are projecting June 10 (based on Monte
>> Carlo modeling), but this could slip. In any event, once we finish
>> milestone 1, moving to OpenStack Gerrit and infrastructure in general ASAP
>> would make sense.
>>
>> In other words, it should be quite soon!
>>
>> - Jim
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
>
> ~ sean
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Tim Bell]

Slight concern on how to deploy on a RHEL system base as software collections 
are non-trivial.

If we can keep the client to be still python 2.X compatible, that would be a 
significant help.

Getting good development productivity/deployments should probably outweigh 
these concerns though…

Tim

From: Jim Baker <jim.ba...@python.org>
Date: Wednesday 25 May 2016 at 00:51
To: Sam Morrison <sorri...@gmail.com>
Cc: openstack-operators <openstack-operators@lists.openstack.org>
Subject: Re: [Openstack-operators] [craton] Versions of Python to support for 
Craton

On Tue, May 24, 2016 at 6:36 PM, Sam Morrison 
<sorri...@gmail.com<mailto:sorri...@gmail.com>> wrote:
I’m in favour of using 3.5. We are in the process of moving things to ubuntu 
xenial and 3.5 is native there.

Thanks for the feedback!


BTW when is Craton planning on getting into openstack gerrit etc?

The specific timeline of the move to gerrit is not something we have actively 
discussed, because of the usual: we are trying to complete our phase 1 
milestone. Currently we are projecting June 10 (based on Monte Carlo modeling), 
but this could slip. In any event, once we finish milestone 1, moving to 
OpenStack Gerrit and infrastructure in general ASAP would make sense.

In other words, it should be quite soon!

- Jim
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[sean roberts]

Now that we have settled on the name, setting up the project infrastructure
is straightforward. I have done this a few times and am ready to do it for
craton.

On Tue, May 24, 2016 at 3:51 PM, Jim Baker  wrote:

> On Tue, May 24, 2016 at 6:36 PM, Sam Morrison  wrote:
>
>> I’m in favour of using 3.5. We are in the process of moving things to
>> ubuntu xenial and 3.5 is native there.
>>
>
> Thanks for the feedback!
>
>
>>
>> BTW when is Craton planning on getting into openstack gerrit etc?
>>
>
> The specific timeline of the move to gerrit is not something we have
> actively discussed, because of the usual: we are trying to complete our
> phase 1 milestone. Currently we are projecting June 10 (based on Monte
> Carlo modeling), but this could slip. In any event, once we finish
> milestone 1, moving to OpenStack Gerrit and infrastructure in general ASAP
> would make sense.
>
> In other words, it should be quite soon!
>
> - Jim
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

~ sean
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Jim Baker]

On Tue, May 24, 2016 at 6:36 PM, Sam Morrison  wrote:

> I’m in favour of using 3.5. We are in the process of moving things to
> ubuntu xenial and 3.5 is native there.
>

Thanks for the feedback!


>
> BTW when is Craton planning on getting into openstack gerrit etc?
>

The specific timeline of the move to gerrit is not something we have
actively discussed, because of the usual: we are trying to complete our
phase 1 milestone. Currently we are projecting June 10 (based on Monte
Carlo modeling), but this could slip. In any event, once we finish
milestone 1, moving to OpenStack Gerrit and infrastructure in general ASAP
would make sense.

In other words, it should be quite soon!

- Jim
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

[Sam Morrison]

I’m in favour of using 3.5. We are in the process of moving things to ubuntu 
xenial and 3.5 is native there.

BTW when is Craton planning on getting into openstack gerrit etc?

Sam




> On 25 May 2016, at 6:20 AM, Jim Baker  wrote:
> 
> tl;dr - any reason why Craton should support Python 2.7 for your use case?
> 
> First, some background: Craton is a fleet management tool under active 
> development for standing up and maintaining OpenStack clouds. It does so by 
> supporting inventory and audit/remediation workflows, both at scale and being 
> pluggable. This architecture follows the model used by Rackspace public 
> cloud; you can think of Craton as being the "2.0" version of what we use at 
> Rackspace. Currently most of the developers are part of OSIC (so Rackspace, 
> Intel). Craton is built on top of a variety of Oslo libraries (notably 
> TaskFlow), but otherwise has no dependence on OpenStack components. Craton 
> itself in turn relies on other tooling like OpenStack Ansible to actually do 
> its work - we have no agents. More details here: 
> https://etherpad.openstack.org/p/Fleet_Management 
> 
> 
> We plan to make Craton a big tent OpenStack project.
> 
> Since we are so brand new, we are trying to make the most of being 
> greenfield. Ubuntu policy is to target new Python development only against 
> Python 3. Other distros are similarly favoring Python 3; see 
> https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions
>  
> 
> 
> Currently we run tox tests against both Python 2.7 and Python 3 (specifically 
> 3.4, 3.5). For interested operators, is there a good reason why we should 
> continue supporting 2.7?
> 
> Such change will let us:
> Reduce development effort, because we will have not to use awkward constructs 
> for dual support of Python 2.7 and Python 3.
> Enable use of new functionality without backports (examples: chainmap, 
> futurist, ipaddress, etc).
> Take advantage of new functionality that has no backport support at all. 
> Python 2.7 at this point only gets security updates.
> We may also want to further simplify by requiring a minimum of Python 3.5. 
> Doing so would enable us to take advantage of static type hinting, for higher 
> quality code. Feedback on that is also appreciated.
> 
> - Jim
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack-operators] [craton] Versions of Python to support for Craton

[Jim Baker]

tl;dr - any reason why Craton should support Python 2.7 for your use case?

First, some background: Craton is a fleet management tool under active
development for standing up and maintaining OpenStack clouds. It does so by
supporting inventory and audit/remediation workflows, both at scale and
being pluggable. This architecture follows the model used by Rackspace
public cloud; you can think of Craton as being the "2.0" version of what we
use at Rackspace. Currently most of the developers are part of OSIC (so
Rackspace, Intel). Craton is built on top of a variety of Oslo libraries
(notably TaskFlow), but otherwise has no dependence on OpenStack
components. Craton itself in turn relies on other tooling like OpenStack
Ansible to actually do its work - *we have no agents*. More details here:
https://etherpad.openstack.org/p/Fleet_Management

We plan to make Craton a big tent OpenStack project.

Since we are so brand new, we are trying to make the most of being
greenfield. Ubuntu policy is to target new Python development only against
Python 3. Other distros are similarly favoring Python 3; see
https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions

Currently we run tox tests against both Python 2.7 and Python 3
(specifically 3.4, 3.5). For interested operators, is there a good reason
why we should continue supporting 2.7?

Such change will let us:

   - Reduce development effort, because we will have not to use awkward
   constructs for dual support of Python 2.7 and Python 3.
   - Enable use of new functionality without backports (examples: chainmap,
   futurist, ipaddress, etc).
   - Take advantage of new functionality that has no backport support at
   all. Python 2.7 at this point only gets security updates.

We may also want to further simplify by requiring a minimum of Python 3.5.
Doing so would enable us to take advantage of static type hinting, for
higher quality code. Feedback on that is also appreciated.

- Jim
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators