Re: [openstack-dev] [tripleo] Recap of Python 3 testing session at PTG

[Thiago da Silva]

On Fri, Apr 13, 2018 at 9:37 AM, Victor Stinner  wrote:

> 2018-04-13 15:07 GMT+02:00 Thomas Goirand :
> > BTW, any progress on upstream Swift WRT Py3 support?
>
> There is a voting Python 3.4 gate which runs 902 unit tests. The
> Python 2.7 gate runs 5,902 unit tests. I compute that 15% of unit
> tests pass on Python 3.4.
>
> I tested locally with Python 3.5 (tox -e py35): 876 tests pass on
> Python 3.5, 57 skipped and 1 failure:
> "FAIL: test_get_logger_sysloghandler_plumbing
> (test.unit.common.test_utils.TestUtils)"
>
There's been some continued effort to port Swift to py3. Our current goal
has been to focus on running the proxy under py3, this way we could start
also running Swift's functional test. Once proxy server and unit/functional
tests have been ported, we could shift focus to account, container, object
servers and finally to background daemons. So yes, there's still a lot of
work to do, but we are making progress.

Thiago

>
> Victor
>
> __
> 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] Boston Forum Schedule

[Thiago da Silva]

Looks like " Swift cluster level metrics and analytics" is also scheduled
twice.

Thiago

>
On Mon, Apr 10, 2017 at 11:03 AM, Tom Fifield  wrote:

> On 10/04/17 22:19, Emilien Macchi wrote:
>
>> On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco 
>> wrote:
>>
>>> On 10/04/17 17:35 +0800, Tom Fifield wrote:
>>>

 Hi everyone,

 Thank you for the many excellent topics submitted for our first Forum.
 We
 have updated the topic submission site with the status of each - please
 check yours.

 Please also find attached in PDF the proposed schedule for the Forum in
 Boston.


 Let us know if you see major issues with it. As Thierry said in design
 summits past; "It's difficult to make too many changes at this stage as
 they
 quickly cascade into breaking all sorts of constraints, but we may
 still be
 able to accommodate some." :)

 Eagle-eyed readers will see that there are a number of slots in gray (on
 Thursday afternoon). These are being deliberately kept aside for the
 usual
 few critical topics that come up in the next few weeks and also for the
 discoveries we make in the first 3 days of the summit.

 We'll soon publish the Forum sessions on the main schedule, using the
 title, abstracts and moderators you submitted, but look forward to your
 feedback in the mean-time!

 Thank you all very much for making our first Forum a success.



>>> Hey Folks,
>>>
>>> Thanks for working on this.
>>>
>>> The topic "Future of configuration management tools" seems to have been
>>> scheduled twice. Is that expected or a mistake? In the schedule it's not
>>> explicit whether it's a 2 parts topic or not.
>>>
>>
>> Good point. I think 1 session to keep is enough and I checked both
>> slots, we can pick one of those, I don't see much conflict that would
>> prevent folks to have to make an hard choice.
>>
>> Tom, any chance to remove the second slot please?
>>
>>
> Yup, this was a mistake, sorry!


>
>
> __
> 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] [tripleo] Default the HA scenario to Ceph

[Thiago da Silva]

On 10/12/2016 07:10 AM, Giulio Fidente wrote:

hi,

we introduced support for the deployment of Ceph in the liberty 
release so that it could optionally be used as backend for one or more 
of Cinder, Glance, Nova and more recently Gnocchi.


We used to deploy Ceph MONs on the controller nodes and Ceph OSDs on 
dedicated ceph-storage nodes so a deployment of OpenStack with Ceph 
would need at least 1 more additional node to host a Ceph OSD.


In our HA scenario the storage backends are configured as follows:

Glance -> Swift
Nova (ephemeral) -> Local
Cinder (persistent) -> LVM (on controllers)
Gnocchi -> Swift

The downside of the above configuration is that Cinder volumes can not 
be replicated across the controller nodes and become unavailable if a 
controller fails, while production environments generally expect 
persistent storage to be highly available. Cinder volumes instead 
could even get lost completely in case of a permanent failure of a 
controller.


With the Newton release and the composable roles we can now deploy 
Ceph OSDs on the compute nodes, removing the requirement we had for an 
additional node to host a Ceph OSD.


I would like to ask for some feedback on the possibility of deploying 
Ceph by default in the HA scenario and use it as backend for Cinder.


Also using Swift as backend for Glance and Gnocchi is enough to cover 
the availability issue for the data, but it also means we're storing 
that data on the controller nodes which might or might not be wanted; 
I don't see a strong reason for defaulting them to Ceph, but it might 
make more sense when Ceph is available; feedback about this would be 
appreciated as well.
I think it would be important to take into account the recently created 
guiding principles [0]:


"While the software that OpenStack produces has well defined and 
documented APIs, the primary output of OpenStack is software, not API 
definitions. We expect people who say they run “OpenStack” to run the 
software produced by and in the community, rather than alternative 
implementations of the API."


In the case of Cinder, I think the situation is a bit muddy as LVM is 
not openstack software, and my limited understanding is that LVM is used 
as a reference implementation, but in the case of Swift, I think RGW 
would be considered an 'alternative implementation of the API'.


Thiago

[0] - 
https://governance.openstack.org/reference/principles.html#openstack-primarily-produces-software


Finally a shared backend (Ceph) for Nova would allow live migrations 
but probably decrease performances for the guests in general; so I'd 
be against defaulting Nova to Ceph. Feedback?



__
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] [elections][tc]Thoughts on the TC election process

[Thiago da Silva]

On 10/11/2016 01:21 PM, Anita Kuno wrote:

On 2016-10-11 12:57 PM, Thiago da Silva wrote:



On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno <ante...@anteaya.info> wrote:

Just in case folks care, now is the best time to discuss our 
election process and suggest options or changes for the next round 
of elections. I'm not adverse to discussing it I just think the 
best time for doing so is from the time the last election is over 
up to milestone one. Then we have lots of time for ideas and debate 
and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and 
electorate.

Agreed.

During the election is a wonderful time for posing questions to 
candidates in order to clarify their position or stance such that 
the electorate can make an informed choice.
To me, that’s the crux: “during the election”. When exactly should 
that be? Candidates can (and do) declare up to the very last minute 
of the nomination window, and ballots go out immediately after that, 
and voting starts. There really needs to be a period when a) we know 
who all the candidates are, and b) voting has not yet begun. I would 
like to see that period be created so that the kind of 
question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place 
for the questions/answers to be stored.


Have you a suggestion for where you would like to see them?

Also regardless of what is formally set up, anyone can ask questions 
via the mailing list, that option has been used every election that I 
have witnessed, I don't see that changing. I don't think it is 
reasonable to ask officials to curate mailing list posts. I think what 
we are discussing is something in addition to mailing list 
discussions. I don't think anything ever would (or should) replace 
what comes up on the mailing list.

Anita,

Agree that the mailing list is irreplaceable, a lot of of the discussion 
would continue to happen here. I also don't think asking anyone to 
curate the answers is scalable.


A *suggestion* would be to come up with a set of questions prior to 
nomination so that candidates could answer in their self-nomination. Of 
course, how we would come up with those questions is then another issue. 
Maybe the questions could even be proposed to the election repo[0], 
starting with an initial set of questions that are then added on by 
others in the community ??? I'm trying to come up with a way to repeat 
what you provided in the '14 election without the burden...


Thiago

[0] - https://github.com/openstack/election/tree/master/candidates/ocata/TC


Thanks,
Anita.

During last week there was a ton of great discussion, but when it 
came to voting time (towards end of the week) it was difficult/time 
consuming to find what each person had said.


-- Ed Leafe






__ 


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] [elections][tc]Thoughts on the TC election process

[Thiago da Silva]

On 10/11/2016 12:00 PM, Ed Leafe wrote:

On Oct 11, 2016, at 10:37 AM, Anita Kuno  wrote:


Just in case folks care, now is the best time to discuss our election process 
and suggest options or changes for the next round of elections. I'm not adverse 
to discussing it I just think the best time for doing so is from the time the 
last election is over up to milestone one. Then we have lots of time for ideas 
and debate and any suggestions, if accepted, have time to be implemented and 
communicated so the process is fair for all, candidates and electorate.

Agreed.


During the election is a wonderful time for posing questions to candidates in 
order to clarify their position or stance such that the electorate can make an 
informed choice.

To me, that’s the crux: “during the election”. When exactly should that be? 
Candidates can (and do) declare up to the very last minute of the nomination 
window, and ballots go out immediately after that, and voting starts. There 
really needs to be a period when a) we know who all the candidates are, and b) 
voting has not yet begun. I would like to see that period be created so that 
the kind of question/answer/clarify process you mention can happen.

+1
Just to add on to that, it would also be nice to have a better place for 
the questions/answers to be stored. During last week there was a ton of 
great discussion, but when it came to voting time (towards end of the 
week) it was difficult/time consuming to find what each person had said.


-- Ed Leafe






__
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] governance proposal worth a visit: Write down OpenStack principles

[Thiago da Silva]

On 09/09/2016 04:27 PM, Doug Hellmann wrote:


Tomato, tomato.

We're all, I think, looking at this "One OpenStack" principle from
different perspectives.  You say "a toolkit". I say "a project".
Thierry said "a product". The important word in all of those phrases
is "a" -- as in singular.
Doug, I'm not sure I can agree with you on that. To use a simple 
example, I could buy *a* remote control car that is very well defined by 
the manufacturer or *a* kit that allows me to build a remote control car 
the way I want, which would probably look very different.


But I *think* what you are getting at, and I agree that we (as a 
community) need to discuss and have a better understanding, is that this 
discussion is really about the autonomy of the projects that make 
openstack. If it's one product, then projects have very little autonomy, 
but if they are a federation, they problably have more autonomy. Reading 
over the IRC chat from 2011 that ttx posted in a earlier email, it 
seemed that the vote was also about that very issue.


Thiago


Doug

__
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